Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #23691 > unrolled thread
| Started by | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| First post | 2013-06-16 23:17 -0700 |
| Last post | 2013-06-27 10:58 -0400 |
| Articles | 20 on this page of 65 — 10 participants |
Back to article view | Back to comp.lang.forth
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-16 23:17 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-17 14:19 +0200
Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-17 16:04 -0700
Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-17 16:15 -0700
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-18 00:01 -0400
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-19 15:33 +0200
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-19 17:25 -0400
Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-19 17:00 -0700
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-20 18:35 -0400
Re: OT (slightly) What is the "best" processor for a new project? Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-19 17:38 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-20 12:51 +0200
Re: OT (slightly) What is the "best" processor for a new project? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-06-20 15:28 +0000
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-20 18:39 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-21 14:50 +0200
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-22 18:56 -0700
Re: OT (slightly) What is the "best" processor for a new project? "WJ" <w_a_x_man@yahoo.com> - 2013-06-23 02:35 +0000
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-22 20:48 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-23 14:49 +0200
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-26 18:08 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-27 16:32 +0200
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-30 10:10 -0700
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-30 15:18 -0400
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-30 16:01 -0700
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-30 20:22 -0400
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-06-30 21:22 +0200
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-30 15:52 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-01 02:02 +0200
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-06-30 19:25 -0700
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-01 02:34 -0500
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-07-01 16:26 -0400
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-01 23:08 +0200
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-07-01 18:10 -0400
Re: OT (slightly) What is the "best" processor for a new project? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-01 12:35 -1000
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-07-01 18:42 -0400
Re: OT (slightly) What is the "best" processor for a new project? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-01 13:03 -1000
Re: OT (slightly) What is the "best" processor for a new project? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-02 07:20 +0000
Re: OT (slightly) What is the "best" processor for a new project? "Elizabeth D. Rather" <erather@forth.com> - 2013-07-02 07:38 -1000
Re: OT (slightly) What is the "best" processor for a new project? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-02 07:24 +0000
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-02 13:02 +0200
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-02 05:58 -0400
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-02 03:34 -0500
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-07-01 20:01 -0700
Re: OT (slightly) What is the "best" processor for a new project? "WJ" <w_a_x_man@yahoo.com> - 2013-07-02 04:43 +0000
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-02 03:41 -0500
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-02 06:09 -0400
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-07-02 13:51 -0700
Re: OT (slightly) What is the "best" processor for a new project? daveyrotten <danw8804@gmail.com> - 2013-07-02 14:37 -0700
Re: OT (slightly) What is the "best" processor for a new project? daveyrotten <danw8804@gmail.com> - 2013-07-02 14:56 -0700
Re: OT (slightly) What is the "best" processor for a new project? Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-03 00:30 +0200
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-03 02:19 -0500
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-03 05:18 -0400
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-07-03 18:10 -0700
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-03 05:30 -0400
Static superinstructions(was: OT (slightly) What is the "best" ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-03 14:33 +0000
Re: Static superinstructions(was: OT (slightly) What is the "best" ...) Bernd Paysan <bernd.paysan@gmx.de> - 2013-07-04 00:41 +0200
Re: Static superinstructions(was: OT (slightly) What is the "best" ...) "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-07 11:32 -0400
Re: OT (slightly) What is the "best" processor for a new project? hughaguilar96@yahoo.com - 2013-07-03 18:31 -0700
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-07 11:28 -0400
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-07-02 16:44 -0400
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-02 05:56 -0400
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-02 05:58 -0500
Re: OT (slightly) What is the "best" processor for a new project? "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-07-03 05:57 -0400
Re: OT (slightly) What is the "best" processor for a new project? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-03 06:43 -0500
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-30 20:29 -0400
Re: OT (slightly) What is the "best" processor for a new project? rickman <gnuarm@gmail.com> - 2013-06-27 10:58 -0400
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-07-02 03:34 -0500 |
| Message-ID | <BtCdnfidFr86DU_MnZ2dnUVZ_rSdnZ2d@supernews.com> |
| In reply to | #24063 |
rickman <gnuarm@gmail.com> wrote: > On 7/1/2013 3:34 AM, Andrew Haley wrote: >> If you have a Forth CPU you don't need to write primitives. There >> are only colon definitions. There is no need to have an assembler, >> because there is only Forth. That is one of the great advantages >> of a Forth processor. > > I have to admit I am guilty of feeding the squirrel on this one, > although I know I shouldn't... but at risk of continuing this inane > conversation further I would ask, are there really *any* processors that > actually implement a complete set of Forth primitives and *only* Forth > primitives? I don't think I've seen one although I may have forgotten > if I had. Sure, Novix did. Unless you have some strange meaning of "only Forth primitives". Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2013-07-01 20:01 -0700 |
| Message-ID | <e8ec1234-c381-45fb-9466-c21b1013c72d@googlegroups.com> |
| In reply to | #24046 |
On Monday, July 1, 2013 12:34:48 AM UTC-7, Andrew Haley wrote: > Hugh is talking as though having an assembler is an advantage. > > I'm having a lot of trouble with all this. If you have a Forth CPU > you don't need to write primitives. There are only colon definitions. > There is no need to have an assembler, because there is only Forth. > That is one of the great advantages of a Forth processor. You have hundreds of words that would normally be primitives, but which are colon words instead. For example, if R@ is a primitive, then you might write DUP like this: : DUP >R R@ R> ; Or, if DUP is a primitive, write R@ like this: :MACRO R@ R> DUP >R ; This would only be described as a "great advantage" by somebody who is unable or unwilling to learn assembly-language --- counting "programmers" like WJ (Ruby) and Passaniti (Perl), that is about 99.9% of the programming population --- for real programmers though, that kind of code is just painful. Especially bad is when the processor doesn't optimize threading --- on the B16, CALL and RET each take a clock cycle --- but it would be painful even with optimization of threading. I'm just repeating myself though --- all of this was said weeks ago --- these threads become like the torment of Sisyphus after a while.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2013-07-02 04:43 +0000 |
| Message-ID | <kqtlq9$900$1@dont-email.me> |
| In reply to | #24078 |
hughaguilar96@yahoo.com wrote: > This would only be described as a "great advantage" by > somebody who is unable or unwilling to learn > assembly-language --- counting "programmers" like WJ (Ruby) > and Passaniti (Perl), that is about 99.9% of the programming > population --- for real programmers though, that kind of code > is just painful. I broke your lines for you. Anyone who knows anything whatsoever about usenet knows that he must limit the length of his lines. You have been told this before, but you lack the human capability to learn. You couldn't learn Racket; you couldn't learn Ruby; you couldn't learn Lua. Your comment is like saying that an engineer who uses off-the-shelf gears in his machine instead of designing his own isn't really an engineer. You can understand only a stone-age language like Forth or assembly language. A troglodyte sneers at those who understand the wheel and metal-working and insists that nothing more sophisticated than a wooden club must be used. Since you are incapable of understanding high-level languages, you are one of the most unproductive and inefficient "programmers" in the world.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-07-02 03:41 -0500 |
| Message-ID | <8vCdnYeb3YfLD0_MnZ2dnUVZ_s6dnZ2d@supernews.com> |
| In reply to | #24078 |
hughaguilar96@yahoo.com wrote: > On Monday, July 1, 2013 12:34:48 AM UTC-7, Andrew Haley wrote: >> Hugh is talking as though having an assembler is an advantage. >> >> I'm having a lot of trouble with all this. If you have a Forth CPU >> you don't need to write primitives. There are only colon definitions. >> There is no need to have an assembler, because there is only Forth. >> That is one of the great advantages of a Forth processor. > > You have hundreds of words that would normally be primitives, Normally? Simce when did Forth normally have hundreds of primitives? Not any Forth I've seen. > but which are colon words instead. Much better. That's the Forth way to do it. > For example, if R@ is a primitive, > then you might write DUP like this; Why wouldn't DUP be an instruction? > : DUP >R R@ R> ; > Or, if DUP is a primitive, write R@ like this: > :MACRO R@ R> DUP >R ; Well, that'd be stupid. > I'm just repeating myself though --- all of this was said weeks ago > --- these threads become like the torment of Sisyphus after a while. Rather than repeating yourself, it might be more successful if you presented an argument that had some chance of convincing. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-02 06:09 -0400 |
| Message-ID | <kqu8jt$ea0$1@speranza.aioe.org> |
| In reply to | #24085 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message news:8vCdnYeb3YfLD0_MnZ2dnUVZ_s6dnZ2d@supernews.com... > hughaguilar96@yahoo.com wrote: > > On Monday, July 1, 2013 12:34:48 AM UTC-7, Andrew Haley wrote: > >> Hugh is talking as though having an assembler is an advantage. > >> > >> I'm having a lot of trouble with all this. If you have a > >> Forth CPU you don't need to write primitives. There > >> are only colon definitions. There is no need to have an > >> assembler, because there is only Forth. > >> That is one of the great advantages of a Forth processor. > > > > You have hundreds of words that would normally be primitives, > > Normally? Si[n]ce when did Forth normally have hundreds > of primitives? Not any Forth I've seen. It's not normal. There are some Forths that have many Forth words or functions. FORTH 1970 and MVP-FORTH had over 200. F83 and F-PC have thousands. But, as for primitives, 4 to 75 is normal, with 20 to 60 being the mid-range. 60 to 63 was considered the "essence" of Forth as attributed to Charles Moore. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2013-07-02 13:51 -0700 |
| Message-ID | <dc1b1c8b-3ea7-4ea6-9ff5-9f0edc7c2d48@googlegroups.com> |
| In reply to | #24085 |
On Tuesday, July 2, 2013 1:41:58 AM UTC-7, Andrew Haley wrote: > hughaguilar96@yahoo.com wrote: > > You have hundreds of words that would normally be primitives, > > Normally? Simce when did Forth normally have hundreds of primitives? > Not any Forth I've seen. Apparently what you've seen are 1980s vintage Forths that don't do any optimization at all. If you are going to have any speed, then it is necessary to make primitives out of common combos. For example: OVER_+ should be a primitive. This is generally faster than OVER followed by +, and it halves the memory usage in the threaded code. In CAMForth that I'm writing, I have almost 500 primitives already, and I'll likely have about 1000 when I'm done. The 64-bit x86 has a 32Kbyte code cache, so this is reasonable. Ironically, a micro-controller such as the PIC24 allows for a lot more primitives as it doesn't have a code-cache but its code memory is something like 128Kwords. > > but which are colon words instead. > > Much better. That's the Forth way to do it. Just as a general rule of thumb: whenever people claiming to be experts in language X use phrases such as "the X way" or "idiomatic for X" --- this means that they are full of hot air, and they don't have any explanation for their opinions. > > For example, if R@ is a primitive, > > then you might write DUP like this; > > Why wouldn't DUP be an instruction? > > > : DUP >R R@ R> ; > > Or, if DUP is a primitive, write R@ like this: > > :MACRO R@ R> DUP >R ; > > Well, that'd be stupid. There are only 32 primitives in most of the so-called "Forth chips." Trade-offs have to be made. Even with 64 primitives, trade-offs are going to have to be made --- and you are going to need a monster chip to support 64 primitives all in hardware. Even supporting 32 primitives in hardware requires a pretty big chip --- I suspect that the chips Payson is using for his B16 are gigantic compared to the Lattice isp1048 that the MiniForth ran on. Testra rejected the original idea that the MiniForth would be like the B16 and support 32 primitives in hardware --- this was partially because it would be grossly inefficient in both speed and memory usage, and partially because it seemed unlikely that the Lattice PLD would be capable of supporting such a big design.
[toc] | [prev] | [next] | [standalone]
| From | daveyrotten <danw8804@gmail.com> |
|---|---|
| Date | 2013-07-02 14:37 -0700 |
| Message-ID | <dff1499b-7f82-4ef9-b6a5-5b57f91ff567@googlegroups.com> |
| In reply to | #24100 |
> > If you are going to have any speed, then it is necessary to make primitives out of common combos. For example: OVER_+ should be a primitive. This is generally faster than OVER followed by +, and it halves the memory usage in the threaded code. > Rick, I think what Hugh is saying is that if you can combine multiple opcodes into a single instruction it would run faster than if each instruction word only had a single opcode. But it seems like you can do that with the B16 also. There is room in each instruction for 3 opcodes (plus a fourth which could be some small subset of the 32 opcodes available, if I understand it correctly). So you CAN have a primitive instruction called "over_+" that combines the two opcodes in one instruction word. They still execute sequentially but you save the calls and returns, and as Hugh says, it halves the memory usage. So... check my math, but I believe that means that a B16 system could have more than 3**32 = 32,768 primitives.
[toc] | [prev] | [next] | [standalone]
| From | daveyrotten <danw8804@gmail.com> |
|---|---|
| Date | 2013-07-02 14:56 -0700 |
| Message-ID | <6c5f8a46-48d3-4fd1-a4b7-d3138cc31dd0@googlegroups.com> |
| In reply to | #24101 |
On Tuesday, July 2, 2013 4:37:09 PM UTC-5, daveyrotten wrote: > > > > > If you are going to have any speed, then it is necessary to make primitives out of common combos. For example: OVER_+ should be a primitive. This is generally faster than OVER followed by +, and it halves the memory usage in the threaded code. > > > > > > > Rick, I think what Hugh is saying is that if you can combine multiple opcodes into a single instruction it would run faster than if each instruction word only had a single opcode. But it seems like you can do that with the B16 also. There is room in each instruction for 3 opcodes (plus a fourth which could be some small subset of the 32 opcodes available, if I understand it correctly). So you CAN have a primitive instruction called "over_+" that combines the two opcodes in one instruction word. They still execute sequentially but you save the calls and returns, and as Hugh says, it halves the memory usage. So... check my math, but I believe that means that a B16 system could have more than > > 3**32 = 32,768 primitives. Sorry, I meant 32**3 = 32,768 primitives.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-07-03 00:30 +0200 |
| Message-ID | <kqvk9a$s3r$1@online.de> |
| In reply to | #24100 |
hughaguilar96@yahoo.com wrote: > Even supporting 32 primitives in hardware requires a pretty big chip --- I > suspect that the chips Payson is using for his B16 are gigantic compared > to the Lattice isp1048 that the MiniForth ran on. We had that discussion already, the b16 is ~600 LEs, should fit into a device of the isp1048 class. Though I would certainly not chose a device without carry chains in the LEs and without Verilog support... but it should fit into similar sized MAX V CPLDs. Today, this is really not a good option, as using a device with embedded memory helps a lot. And we have already discussed that the b16 was and is used in ASICs, not in PLDs or FPGAs - the FPGA is just for prototyping and demos. Yes the FPGA used for demos is gigantic, and almost empty. The size of the b16 in silicon was always significantly smaller than the program memory - and the b16 has pretty compact programs. The 8k bytes PIC16 program for the battery controller did fit into 2k with the b16. The b16 was a good choice for several projects, all somewhat different, all requiring somewhat different choices, and adaptions to the b16 code base. The first project was done by a coworker who added more instructions, and therefore expanded the instruction field to 6 bits, but it still was pretty small. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-07-03 02:19 -0500 |
| Message-ID | <PoGdnfhSBboDTU7MnZ2dnUVZ_vydnZ2d@supernews.com> |
| In reply to | #24100 |
hughaguilar96@yahoo.com wrote: > On Tuesday, July 2, 2013 1:41:58 AM UTC-7, Andrew Haley wrote: >> hughaguilar96@yahoo.com wrote: >> > You have hundreds of words that would normally be primitives, >> >> Normally? Simce when did Forth normally have hundreds of primitives? >> Not any Forth I've seen. > > Apparently what you've seen are 1980s vintage Forths that don't do > any optimization at all. I wonder why you say that. > If you are going to have any speed, then it is necessary to make > primitives out of common combos. For example: OVER_+ should be a > primitive. This is generally faster than OVER followed by +, and it > halves the memory usage in the threaded code. Possibly. But if you're going to such lengths it would make more sense to optimize than to use straight threaded code. > In CAMForth that I'm writing, I have almost 500 primitives already, > and I'll likely have about 1000 when I'm done. This sounds like the most badly-designed Forth I've ever heard of. If you're going to such lengths it makes no sense to have so many primitives. Just optimize. >> > but which are colon words instead. >> >> Much better. That's the Forth way to do it. > > Just as a general rule of thumb: whenever people claiming to be > experts in language X use phrases such as "the X way" or "idiomatic > for X" --- this means that they are full of hot air, and they don't > have any explanation for their opinions. Pot, meet kettle. > There are only 32 primitives in most of the so-called "Forth chips." It's a trade-off. You're trading instruction density for flexibility. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-03 05:18 -0400 |
| Message-ID | <kr0q1t$2rn$1@speranza.aioe.org> |
| In reply to | #24109 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message news:PoGdnfhSBboDTU7MnZ2dnUVZ_vydnZ2d@supernews.com... > hughaguilar96@yahoo.com wrote: > > On Tuesday, July 2, 2013 1:41:58 AM UTC-7, Andrew Haley wrote: > >> hughaguilar96@yahoo.com wrote: > > In CAMForth that I'm writing, I have almost 500 primitives > > already, and I'll likely have about 1000 when I'm done. > > This sounds like the most badly-designed Forth I've ever heard > of. If you're going to such lengths it makes no sense to have > so many primitives. Just optimize. > My guesses: 1) He has no optimizer. So, he'd have to code the optimizer. 2) Since he's likely coding this in assembly, *everything* becomes a primitive... 3) It's entirely possible it's STC without the threading, i.e., straight assembly. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2013-07-03 18:10 -0700 |
| Message-ID | <15a4cb0e-4d5c-411b-aac3-6633b10d8478@googlegroups.com> |
| In reply to | #24109 |
On Wednesday, July 3, 2013 12:19:58 AM UTC-7, Andrew Haley wrote: > hughaguilar96@yahoo.com wrote: > > In CAMForth that I'm writing, I have almost 500 primitives already, > > and I'll likely have about 1000 when I'm done. > > This sounds like the most badly-designed Forth I've ever heard of. If > you're going to such lengths it makes no sense to have so many > primitives. Just optimize. I am optimizing. The user doesn't know about all of the primitives. For example, he doesn't write OVER_+ in his source-code. My compiler sees OVER followed by + in the program, and it compiles OVER_+ instead. It is not just combos of two, but also three and four. So I'm optimizing, while yet having an ITC system --- maybe later I will take the leap into STC. I actually started with STC in the HLA version, but I switched from HLA to FASM so I could have 64-bit support, and I also switched from STC to ITC at that same time.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-03 05:30 -0400 |
| Message-ID | <kr0qmq$4vd$1@speranza.aioe.org> |
| In reply to | #24100 |
<hughaguilar96@yahoo.com> wrote in message news:dc1b1c8b-3ea7-4ea6-9ff5-9f0edc7c2d48@googlegroups.com... > If you are going to have any speed, then it is necessary > to make primitives out of common combos. Hugh, I've already told you, like three times now, that this premise doesn't follow, mathematically. > For example: OVER_+ should be a primitive. This is > generally faster than OVER followed by +, and it > halves the memory usage in the threaded code. The probability of any Forth instruction being executed is really low, even for the heavy usage instructions, of which there are only a few. See the work by Philip Koopman or Anton Ertl on instruction frequencies. The probability of any combination of two operations being executed is even lower, substantially lower in fact. So, how exactly can optimizing a bunch of extremely low use operations result in faster performance? These combinations would have to execute many, many times to have any measurable effect. Just how is that going to happen? How many times are you going to code "OVER +" in typical code? How many times is it going to execute? If it's a specialty situation or used in an infinite loop, then, yes, "OVER +" could occur or execute frequently. If so, it's time to implement and optimize "OVER +". However, that's atypical. So, I think it's high time to ask your mathematics "professor" brother to explain the "essence" of probability to you. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2013-07-03 14:33 +0000 |
| Subject | Static superinstructions(was: OT (slightly) What is the "best" ...) |
| Message-ID | <2013Jul3.163310@mips.complang.tuwien.ac.at> |
| In reply to | #24114 |
"Rod Pemberton" <do_not_have@notemailnotq.cpm> writes:
>> For example: OVER_+ should be a primitive. This is
>> generally faster than OVER followed by +, and it
>> halves the memory usage in the threaded code.
>
>The probability of any Forth instruction being executed is really
>low, even for the heavy usage instructions, of which there are only
>a few. See the work by Philip Koopman or Anton Ertl on instruction
>frequencies.
Well, looking at <http://www.complang.tuwien.ac.at/forth/peep/sorted>,
primitives like ;s (EXIT), col: (colon definition entry routine), @,
?branch (if), lit, var: (CREATEd word entry routine), dup, user:,
swap, + are pretty frequent, constituting between 3% (+) and 13% (;s)
of all NEXTs. There are also some frequent dynamic sequences, in
particular col: col: (4.5%), user: @ (2.7%), @ ;s (2.7%), ;s ;s
(2.7%), var: @ (2.5%). "over +" is relatively rare, though, at 0.14%
of the frequency of NEXT.
Some of these dynamic sequences (e.g., col: col: and ;s ;s) do not
correspond to static sequences and can therefore not be optimized
through simple static superinstructions. But, e.g., tail call
optimization would reduce the number of occurences of ;s ;s.
<http://www.complang.tuwien.ac.at/forth/peep/> says the following about
this data:
|Not all of the dynamic sequences shown in the data can be combined
|into one primitive by a simple compiler. E.g., if they contain a
|primitive that changes the control flow (e.g., docol, ;s, branch,
|dodefer) on any but the last position, the sequence cannot be combined
|(easily). Moreover, when two sequences overlap, only one of them can
|be combined.
|
|The following table shows how many distinct sequences of a given
|length appear in the applications and what portion of the dynamic
|sequences is covered by the top 20 (50,100,200) most frequently
|occuring sequences. Note that the number of dynamic sequences of
|length n is #dynprimitives-n+1.
|
|length distinct %top20 %top50 %top100 %top200
|1 160 75.53 94.219 99.832 100
|2 1278 31.1074 48.8859 65.3516 83.112
|3 3321 16.7137 31.2978 44.3291 62.3914
|4 5489 13.1306 25.8037 36.8787 53.2986
|5 7423 11.8311 23.5362 34.1386 49.9976
|6 9138 11.0131 22.015 32.3519 47.7475
|
|Eliminating sequences, that cannot be combined because they contain a
|control flow change in the wrong place reduces the portion of the
|length-2 top-100 from 65% to 45%. I do not have an accurate result for
|the effect of overlapping sequences; however, for length-2 sequences
|the overlap can at most halve the number of combinable sequences.
We found in later work, though, that dynamic frequency of sequences in
a bunch of applications is a poor predictor of dynamic frequency in
different applications (dynamic frequency overemphasizes inner loops).
We also did quite a bit more work on static superinstructions
(published in various papers), and we have very decent (and automatic)
support for static superinstructions in Gforth: You just put in a
line like
super_over_+ = over +
in the primitives specification file, and when you build Gforth, it
generates the code for the superinstruction, and gforth-fast will
automatically replace the sequence OVER + with this superinstruction
if it is profitable.
When writing the papers I used this feature for up to 1600
superinstructions. In production, we currently use only 13
superinstructions, for the following reasons: 1) Dynamic
superinstructions give more speedup than static superinstructions, and
once they are there, static superinstructions (even if you have a lot)
provide little additional benefit (see below). Moreover, Gforth now
supports stack caching, which covers even more of the ground covered
by static superinstructions. 2) Some bug appeared at some point (maybe
with some gcc version) that could be eliminated by reducing the number
of superinstructions; given that there was little benefit of having
many, I reduced them.
Concerning the benefit of having many superinstructions, most of it is
due to having more indirect branches in the interpreter, leading to
better indirect branch prediction. That part is covered much better
by dynamic superinstructions with replication (i.e., simply
concatenating the native code of the primitives in straight-line
code). Another part comes from reducing stack accesses and stack
pointer updates. Looking at Figure 10 of
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg03.ps.gz>, the
effect of the latter is relatively small.
Figure 13 of that paper
<http://www.complang.tuwien.ac.at/papers/ertl%26gregg03.ps.gz> shows
the effectiveness of different numbers of static superinstructions
(the right end of the graph). Having more than 400 static
superinstructions buys little, and having more than 800 buys nothing.
Also, just having several replicas of the same primitive (and using
them alternatingly) improves performance (if your CPU has a BTB),
often better than the same number of static superinstructions, because
of better coverage. Combining static replicas with static
superinstructions produces best results among static methods.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2013-07-04 00:41 +0200 |
| Subject | Re: Static superinstructions(was: OT (slightly) What is the "best" ...) |
| Message-ID | <kr29bn$9eb$1@online.de> |
| In reply to | #24120 |
Anton Ertl wrote: > 2) Some bug appeared at some point (maybe > with some gcc version) that could be eliminated by reducing the number > of superinstructions; given that there was little benefit of having > many, I reduced them. Yes, but I "fixed" that bug in the meantime, as GCC 4.7.x had that bug even for the just 13 superinstructions, so it had to be worked around. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-07 11:32 -0400 |
| Subject | Re: Static superinstructions(was: OT (slightly) What is the "best" ...) |
| Message-ID | <krc1do$os4$1@speranza.aioe.org> |
| In reply to | #24120 |
"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message news:2013Jul3.163310@mips.complang.tuwien.ac.at... > "Rod Pemberton" <do_not_have@notemailnotq.cpm> writes: > >> For example: OVER_+ should be a primitive. This is > >> generally faster than OVER followed by +, and it > >> halves the memory usage in the threaded code. > > > >The probability of any Forth instruction being executed is > >really low, even for the heavy usage instructions, of which > >there are only a few. See the work by Philip Koopman or > >Anton Ertl on instruction frequencies. > > Well, looking at <[link]>, > primitives like ;s (EXIT), col: (colon definition entry routine), > @, ?branch (if), lit, var: (CREATEd word entry routine), dup, > user:, swap, + are pretty frequent, constituting between 3% (+) > and 13% (;s) of all NEXTs. There are also some frequent > dynamic sequences, in particular col: col: (4.5%), user: > @ (2.7%), @ ;s (2.7%), ;s ;s (2.7%), var: @ (2.5%). "over +" > is relatively rare, though, at 0.14% of the frequency of NEXT. > 3% is frequent? 30% is frequent. Yes, 3% is frequent relative to the non-frequent instructions. > When writing the papers I used this feature for up to 1600 > superinstructions. In production, we currently use only 13 > superinstructions, for the following reasons: 1) Dynamic > superinstructions give more speedup than static > superinstructions, and once they are there, static > superinstructions (even if you have a lot) > provide little additional benefit (see below). Hopefully, Hugh read what you just said about static superinstructions. > [SNIP] > Concerning the benefit of having many superinstructions, > most of it is due to having more indirect branches in the > interpreter, leading to better indirect branch prediction. It seems like you're solving the wrong problem, or solving it indirectly. I.e., shouldn't you find a way optimize the branches without creating superinstructions? > [SNIP] Most of what you mentioned seemed to be ways to implement rudimentary code optimization. Rod Pemberton.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2013-07-03 18:31 -0700 |
| Message-ID | <bfa09a31-404d-408e-bc33-25576c62378f@googlegroups.com> |
| In reply to | #24114 |
On Wednesday, July 3, 2013 2:30:07 AM UTC-7, Rod Pemberton wrote: > <hughaguilar96@yahoo.com> wrote in message > news:dc1b1c8b-3ea7-4ea6-9ff5-9f0edc7c2d48@googlegroups.com... > > > If you are going to have any speed, then it is necessary > > to make primitives out of common combos. > > Hugh, I've already told you, like three times now, that this > premise doesn't follow, mathematically. > > > For example: OVER_+ should be a primitive. This is > > generally faster than OVER followed by +, and it > > halves the memory usage in the threaded code. > > The probability of any Forth instruction being executed is really > low, even for the heavy usage instructions, of which there are only > a few. See the work by Philip Koopman or Anton Ertl on instruction > frequencies. The probability of any combination of two operations > being executed is even lower, substantially lower in fact. So, how > exactly can optimizing a bunch of extremely low use operations > result in faster performance? These combinations would have to > execute many, many times to have any measurable effect. Just how > is that going to happen? How many times are you going to code > "OVER +" in typical code? How many times is it going to execute? This is an argument against the B16 design, not against the MiniForth design! The B16 packs three 5-bit codes together into a single 16-bit cell. So, as daveyrotten says, you effectively have 32^3=32768 primitives. But the vast majority of those combos will never appear in any program, and most will appear only very rarely. Less than 500 will get much use at all. What I have found (relying on casual inspection with a heavy dose of intuition), is that Forth code mostly alternates between "producers" and "consumers." You have words that push data onto the stack, followed by words that remove data from the stack. OVER_+ is a classic example: OVER is a producer and + is a consumer. In my CAMForth, the majority if my hundreds of primitives are producer-consumer pairs. These are not only common, but they also lend themselves to being written as a pair --- because they can hold the data in a register internally, rather than push it onto the stack and then immediately pop it off the stack. The B16 is not using registers to hold data internally for producer-consumer pairs such as OVER followed by +. It is just using memory --- pushing the data onto the stack and then immediately popping the data off the stack. > So, I think it's high time to ask your mathematics "professor" > brother to explain the "essence" of probability to you. Leave my family out of this, you whoreson troll!
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-07 11:28 -0400 |
| Message-ID | <krc162$o4q$1@speranza.aioe.org> |
| In reply to | #24128 |
<hughaguilar96@yahoo.com> wrote in message news:bfa09a31-404d-408e-bc33-25576c62378f@googlegroups.com... > On Wednesday, July 3, 2013 2:30:07 AM UTC-7, Rod Pemberton wrote: > > So, I think it's high time to ask your mathematics "professor" > > brother to explain the "essence" of probability to you. > > Leave my family out of this, you whoreson troll! > You're like a grenade. Some days the pin is in, and others it's pulled. So, I just never know when you're going to go off or why. Therefore, I'm confused. Why are you angry at me this time? Are you angry with your brother and projecting that anger on me because you're mad at him? Or, are you angry at me for just mentioning him? If the former, I can't help you with that. If the latter, when *you* mentioned him previously, about a year ago, you seemed proud of him. You said he was a "math major" who graduated. A family member with a degree presumed to be in math seemed like an excellent choice to help you with probability based design decisions of a Forth interpreter. Doesn't it? Well, it did to me. He doesn't have to teach you the math, just the basic concepts or principles. That's like five minutes, tops, if you listen... Or, he could just review the viability of some of your ideas for you with regards to probability. Seriously, how are you going to get CamForth off the ground without some help from your family? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-07-02 16:44 -0400 |
| Message-ID | <kqvdoh$1k8$2@dont-email.me> |
| In reply to | #24078 |
On 7/1/2013 11:01 PM, hughaguilar96@yahoo.com wrote: > On Monday, July 1, 2013 12:34:48 AM UTC-7, Andrew Haley wrote: >> Hugh is talking as though having an assembler is an advantage. >> >> I'm having a lot of trouble with all this. If you have a Forth CPU >> you don't need to write primitives. There are only colon definitions. >> There is no need to have an assembler, because there is only Forth. >> That is one of the great advantages of a Forth processor. > > You have hundreds of words that would normally be primitives, but which are colon words instead. For example, if R@ is a primitive, then you might write DUP like this: > : DUP>R R@ R> ; > Or, if DUP is a primitive, write R@ like this: > :MACRO R@ R> DUP>R ; > > This would only be described as a "great advantage" by somebody who is unable or unwilling to learn assembly-language --- counting "programmers" like WJ (Ruby) and Passaniti (Perl), that is about 99.9% of the programming population --- for real programmers though, that kind of code is just painful. Especially bad is when the processor doesn't optimize threading --- on the B16, CALL and RET each take a clock cycle --- but it would be painful even with optimization of threading. > > I'm just repeating myself though --- all of this was said weeks ago --- these threads become like the torment of Sisyphus after a while. I don't know if you are repeating yourself, but you aren't making a lot of sense to me. How about if we stick to the technical stuff and not bother to disrespect others who aren't in our little conversation. That will make it easier for me to keep a train of thought. So just what the heck are you trying to say? If you are working with a "forth" CPU, the instructions of the CPU are forth words. It is not likely that the instructions will be the full set of Forth as defined in the standard, even just the core words are a large set and not likely to be implemented as CPU instructions. So why are you obsessing about the "primitives"? Why is it so important for R@ to be highly optimized? Have you ever heard of optimizing compilers? I just don't get what you are trying to say. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotq.cpm> |
|---|---|
| Date | 2013-07-02 05:56 -0400 |
| Message-ID | <kqu7rh$c8a$1@speranza.aioe.org> |
| In reply to | #24046 |
"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message news:0--dnSWLJo-FrEzMnZ2dnUVZ_rCdnZ2d@supernews.com... > Hugh is talking as though having an assembler is an advantage. > > I'm having a lot of trouble with all this. ... > If you have a Forth CPU you don't need to write primitives. Why? Your statement assumes that all the necessary primitives are available. I.e., if DUP and ROT are not present, then you have a "need to write primitives." > There are only colon definitions. If and only if, all the necessary primitives for building a complete Forth are available. What defines "complete" here is arbitrary since it's unspecified. > There is no need to have an assembler, because there is only > Forth. With all the necessary primitives are available, that would be true. > That is one of the great advantages of a Forth processor. Really? From what I've seen (from about 30 different Forths), most of the Forth primitives used in a variety of different Forths map to standard features available on all or almost all microprocessors. Although, there are a few Forths that use primitives that are too rudimentary even for a microprocessor, but that's not the norm, e.g., AND OR XOR built from NAND NOR, etc. This all goes back to the issue of what exactly is a "primitive," which I asked about here some years ago. I didn't come to a conclusion of what primitive is, but I eventually came to my own conclusions of what should be a primitive. This resulted in a list that could be used as a guide to decide when to stop factoring or reducing the Forth operation any further. E.g., you're not going to spend time to factor or reduce a standard feature of microprocessors such as logical and binary operations, like AND, OR, or NOR, or arithmetic like addition and subtraction. You're generally not going to spend time reducing simple stack operations, like DUP, ROT, SWAP, DROP, unless optimizing for size or speed. You're not going to implement features readily available to you. E.g., for x86, there are string instructions, e.g., MOSVB, CMPSB, available for moving and comparing strings, etc. E.g., if using a C backend, you'll use some of C's string functions: strcpy(), strcmp(), strlen(), and null terminated strings. You'd also use some of C's character I/O: putc(), getc(), printf(). You're not going to implement file I/O other than wrapping the operating system file I/O functions for Forth use. Etc. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web