Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54229 > unrolled thread
| Started by | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| First post | 2017-01-21 11:27 -0800 |
| Last post | 2017-01-23 18:46 -0300 |
| Articles | 18 on this page of 138 — 21 participants |
Back to article view | Back to comp.lang.forth
embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-21 11:27 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-21 11:31 -0800
Re: embedded forth stephen@mpeforth.com - 2017-01-22 00:52 -0800
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 17:09 +0000
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 09:43 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 12:19 -0800
Re: embedded Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-22 21:25 +0100
Re: embedded Forth john <anon@example.com> - 2017-01-22 21:04 +0000
Re: embedded Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-22 12:30 -1000
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 20:45 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 14:08 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 14:55 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 20:41 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 21:19 -0800
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 21:36 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:09 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 04:15 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 08:41 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 14:32 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 11:53 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 15:10 -0500
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 14:34 -0800
Re: embedded Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:14 -0600
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 03:43 -0500
Re: embedded Forth john <anon@example.com> - 2017-01-23 10:32 +0000
keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 08:58 -0300
Re: keep secrets (was Re: embedded Forth) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-23 07:47 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:18 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:15 -0500
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 14:38 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:43 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:48 -0500
Re: keep secrets (was Re: embedded Forth) "Elizabeth D. Rather" <erather@forth.com> - 2017-01-23 16:30 -1000
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 22:23 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-22 13:44 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 13:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 00:45 -0500
Re: embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:44 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 00:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 03:51 -0500
Re: embedded forth john <anon@example.com> - 2017-01-23 10:02 +0000
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-23 09:01 +0000
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-23 13:05 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 14:40 -0500
Re: embedded forth Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:12 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:38 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-24 19:51 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-25 11:34 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-25 22:13 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-26 11:36 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:07 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 00:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 13:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 17:54 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-27 15:29 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 16:28 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 23:58 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 11:58 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 15:36 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 15:05 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-28 15:57 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 09:53 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-29 19:32 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:53 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 01:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 23:11 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-29 23:34 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:42 +0100
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:36 +0100
Re: embedded forth ctmalan@gmail.com - 2017-01-30 11:02 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 11:04 -0800
Re: embedded forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:34 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 10:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:20 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 14:09 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-31 03:04 +0100
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 20:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 17:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 14:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 23:09 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-31 09:32 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 18:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:46 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:11 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 01:30 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-12 10:21 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 19:37 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-14 13:26 -0800
Re: embedded forth Gary Bergstrom <forthprgrmr@gmail.com> - 2017-02-14 11:36 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-14 18:13 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 10:20 -0800
Re: embedded forth Cecil Bayona <cbayona@cbayona.com> - 2017-01-29 12:38 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:49 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-04 04:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-04 17:54 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-04 20:26 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-05 07:53 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:08 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:39 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 06:46 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-13 19:17 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 06:23 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-15 11:09 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 15:24 -0800
Re: embedded forth jkn_gg@nicorp.f9.co.uk - 2017-02-16 09:49 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 09:12 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-17 12:47 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 16:18 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-16 08:43 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 20:47 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 13:36 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 23:18 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:10 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-06 11:12 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:15 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 22:45 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-06 12:04 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 03:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 06:39 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 07:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 15:49 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:14 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:19 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 03:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-05 16:08 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-07 21:59 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 11:10 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 06:15 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:48 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 14:37 -0500
Re: embedded forth mhx@iae.nl - 2017-01-28 07:48 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:53 +0100
Re: embedded forth mhx@iae.nl - 2017-01-28 15:49 -0800
Re: embedded forth "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:46 -0300
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-06 12:04 +0100 |
| Message-ID | <o79l81$t3d$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54669 |
In article <6424f6ad-a958-4108-b387-924559e2ca53@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Sunday, February 5, 2017 at 10:15:40 PM UTC-7, hughag...@gmail.com wrote= >: <SNIP> >This is why I still have LATE-MACRO: in the novice package. > >A good way to develop a complicated function is to first factor out a lot o= >f pieces into smaller functions that your big function calls. These small f= >unctions can be debugged independently of the big function --- that is the = >purpose of factoring. You don't want to leave it like this though, because = >those small functions are sharing global variables with the big function an= >d/or with each other --- this isn't reentrant. The solution then is to conv= >ert all of those small functions into late-binding macros and convert all o= >f the global variables into local variables belonging to the big function -= >-- then you get reentrant code, plus the speed of inlining all of the small= > functions --- I explain this technique in the documentation of the novice = >package for novices who are learning Forth. I think re-entrancy is overrated. Can you give an example of a complicated function where this was essential? Otherwise you could've just left it. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-02-08 03:08 -0800 |
| Message-ID | <0c5b0081-b02a-4fb7-9796-12f3c25a2ed6@googlegroups.com> |
| In reply to | #54650 |
воскресенье, 5 февраля 2017 г., 22:08:13 UTC+3 пользователь hughag...@gmail.com написал: > On Sunday, February 5, 2017 at 8:53:30 AM UTC-7, Ilya Tarasov wrote: > > > This is more robust than your method because there can be any number of primitives --- I had hundreds --- you are limited to 32 or 64 primitives (some small number that can't be increased). > > > > This is a point to discuss. I have several designs with packed commands. This requires a serializer from hardware side (not difficult), but some efforts from the tool side. I leave this idea at last, because of no visible benefits in real applications. > > This has visible benefits in all real applications --- you have more flexibility --- you can write primitives to support that particular application and which are much faster than high-level Forth equivalents. I have other designs, including what you are talking about. Other approaches are: packed commands, variable length (multiple bytes/words), wide command. My 3rd generation Forth CPU was optimized for Spartan-3 FPGA with new (at that time) 1024x18 RAM blocks. Ive try 18-bit command with address filed, so CALL/JMP/short LIT were 1-cycle, and 32-bit literals were splitted to to parts. It was successful emough, with tens designs done. I don't want to strictly base artitectural features on commercial success. Target domains, partner relations, overall economic situation meaning too. However, Spartan-3/3E FPGA families were successful enough, and designs, targeted that families, took their benefits as well. For Gen5 architecture, new 6-inputs LUT are comes, and next low-cost FPGA Spartan-6 appears. Next important thing to improve was targeting LUT acrhitecture, so 6-bit command was used, with appropriate trade-offs. This is not 'final solution' because I don't believe in 'final solutions' :) Similarly, my current design was a certain goal: to fit in lowest cost Xilinx Spartan-6 LX4 FPGA, but still provide several independent threads. This is not because I want to sell it to everyone, but because of certain customer request. > Forth code is factored quite a lot --- you have a lot of short colon words that call other short colon words --- by comparison, in C you have very long functions (I've seen them 100s of lines long) that don't call many other functions but are written mostly in raw C. > > As a result, Forth code benefits a lot by making a call to a colon word 2 bytes just like a call to a primitive is 2 bytes. In your system, a call to a colon word is 4 bytes (2 bytes for the CALL primitive and 2 bytes for the cfa). Using the method I described, threaded-code can be something like 2/3 the size that it would be with your method. > > My method is also faster because there are fewer memory accesses needed when loading threaded code (one to call a colon word, rather than two as with your method). > > I think if you tried out the RACE you would learn new things --- you know a lot already! --- but I can see that there are aspects of Forth that you don't yet know. Yes, this is another possible way. I have this implemented too :) There are two fundamental approach known from processor design - to map additional operaions to IO/memory space or to add it into main CPU pipeline. Xilinx use both in their PowerPC hard IP with special kind acceleration port. Having operands from CPU registers, designer can implement his own command and return it directly to CPU pipeline. This is hard enough for PowerPC, but very easy for soft-core. If we have, say, a big case operand we can easily extend this case to our own operations. > On Monday, May 13, 2013 at 8:07:20 PM UTC-7, rickman wrote: > > He doesn't bother me so much as others. But I realize I have been > > feeding him again. It's just that he's so *cute* when you give him a > > cookie and he does the little dance. > > He is doing the same thing to you now. He is taunting you so that you will do a little dance for him. He can try :) It is clearly to compare, when I put a code here, but he still talks I'm wrong without any pieces of code, which can be proven independently. This is my decision to answer correctly even on incorrect questions. This don't mean I will dance for him - I will dance only on my own :) > Rickman is saying that you are stupid because you use CORDIC, and you should have used polynomial approximations instead. He is just baiting you. If you had been using polynomial approximations though, then he would say that you are stupid and should have used CORDIC instead. This is very childish game. When I told we can take a look on CORDIC, this means we can take a look, nothing more. Table solutions are good for lower size of argument, approximations may be not precise, and exact calculations are scalable. This is a first look on the problem. If someone claims he can provide an approximation better than direct calculation - ok, show me. We can compare complete lists of properties, including accuracy, performance, resources taken etc and choose optimal one. This is a kind of 'committee way' to state 'nobody need your solution' without serious reasons :) > The reason why trolls attack people for their algorithm choice (Rickman calling you stupid for using CORDIC or Alex McDonald calling me stupid for using HeapSort) is because they have a book at home that discusses these algorithms and that is where they get their ammunition to use in their flame war against you. I see his knowledge level. Indeed I can say more about combined time-frequency domains analysis, but this is too early :) However, without stating an opinion, how it can be possible to start a conversation to those who really needs this? Even a complete fool question can be a base to explain how things are going. I wonder why nobody explain yet what is HDMI, USB 3.0, web browser, where are challenges here and where Forth CPU may be applicable. This can be a good base to start a useful discussion, even with poor first example.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-08 06:39 -0500 |
| Message-ID | <o7evtj$f4c$1@dont-email.me> |
| In reply to | #54717 |
On 2/8/2017 6:08 AM, Ilya Tarasov wrote: > воскресенье, 5 февраля 2017 г., 22:08:13 UTC+3 пользователь > hughag...@gmail.com написал: >> On Sunday, February 5, 2017 at 8:53:30 AM UTC-7, Ilya Tarasov >> wrote: >>>> This is more robust than your method because there can be any >>>> number of primitives --- I had hundreds --- you are limited to >>>> 32 or 64 primitives (some small number that can't be >>>> increased). >>> >>> This is a point to discuss. I have several designs with packed >>> commands. This requires a serializer from hardware side (not >>> difficult), but some efforts from the tool side. I leave this >>> idea at last, because of no visible benefits in real >>> applications. >> >> This has visible benefits in all real applications --- you have >> more flexibility --- you can write primitives to support that >> particular application and which are much faster than high-level >> Forth equivalents. > > I have other designs, including what you are talking about. Other > approaches are: packed commands, variable length (multiple > bytes/words), wide command. My 3rd generation Forth CPU was optimized > for Spartan-3 FPGA with new (at that time) 1024x18 RAM blocks. Ive > try 18-bit command with address filed, so CALL/JMP/short LIT were > 1-cycle, and 32-bit literals were splitted to to parts. It was > successful emough, with tens designs done. I have not found packed instructions to be of much use. The designs I have completed used internal RAM for instruction storage, so the RAM speed was not a limiting factor in any way. Packing instructions then just add complexity in the hardware as well as software with no advantage. I've looked at very short instructions and found them a bit lacking. The GA144 uses 5 bit instructions packed into an 18 bit word. This means special things must be done for packing including a number of NOPs to align to word boundaries for literals. The RAM in the GA144 is not as fast as the ALU, so this can give good speed, but hard to calculate. FPGAs are very different from ASICs in many regards that affect stack processor designs. My favorite instruction design uses variable length instruction to optimize density. In stack processors running Forth, literals, jumps and calls are the most common instructions. A 1 bit instruction for a literal uses multiple instructions to extend the length of the literal. This works with 3 bit instructions for calls and jumps which also contain a literal. If that is long enough for a short jump/call then it's a 1 word opcode. Otherwise the literal instruction precedes the jump/call to extend the range of the jump or call. In the end I came to realize there were three execution units in the design, the data stack/alu, the return stack/alu(for addressing and loop control) and the instruction address/alu. It could make sense to provide independent fields in the instruction for each of these so they might be combined in many different ways, not unlike the CPU Hugh talks about and others like the J1. But this complicates the compiler which is a bit beyond my interests. I am more used to coding microcode manually than designing tools to automate it. > I don't want to strictly base artitectural features on commercial > success. Target domains, partner relations, overall economic > situation meaning too. However, Spartan-3/3E FPGA families were > successful enough, and designs, targeted that families, took their > benefits as well. > > For Gen5 architecture, new 6-inputs LUT are comes, and next low-cost > FPGA Spartan-6 appears. Next important thing to improve was targeting > LUT acrhitecture, so 6-bit command was used, with appropriate > trade-offs. This is not 'final solution' because I don't believe in > 'final solutions' :) It is hard to match instruction size to LUT inputs because there are often other inputs such as zero detect, interrupt state, etc. That is a great reason to not have multicycle instructions. The cycle counter becomes more inputs to the instruction decode. > Similarly, my current design was a certain goal: to fit in lowest > cost Xilinx Spartan-6 LX4 FPGA, but still provide several independent > threads. This is not because I want to sell it to everyone, but > because of certain customer request. Do you use the pipeline stages for separate threads? Rather than filling the pipeline with multiple instructions from one thread and flushing when the address is not linear, each phase of the pipeline is treated as a separate thread requiring each register to have N copies. Very little extra logic is needed and this can improve the overall throughput because of the elimination of pipeline stalls. >> Forth code is factored quite a lot --- you have a lot of short >> colon words that call other short colon words --- by comparison, in >> C you have very long functions (I've seen them 100s of lines long) >> that don't call many other functions but are written mostly in raw >> C. >> >> As a result, Forth code benefits a lot by making a call to a colon >> word 2 bytes just like a call to a primitive is 2 bytes. In your >> system, a call to a colon word is 4 bytes (2 bytes for the CALL >> primitive and 2 bytes for the cfa). Using the method I described, >> threaded-code can be something like 2/3 the size that it would be >> with your method. >> >> My method is also faster because there are fewer memory accesses >> needed when loading threaded code (one to call a colon word, rather >> than two as with your method). >> >> I think if you tried out the RACE you would learn new things --- >> you know a lot already! --- but I can see that there are aspects of >> Forth that you don't yet know. > > Yes, this is another possible way. I have this implemented too :) > There are two fundamental approach known from processor design - to > map additional operaions to IO/memory space or to add it into main > CPU pipeline. Xilinx use both in their PowerPC hard IP with special > kind acceleration port. Having operands from CPU registers, designer > can implement his own command and return it directly to CPU pipeline. > This is hard enough for PowerPC, but very easy for soft-core. If we > have, say, a big case operand we can easily extend this case to our > own operations. The Propeller approach is to use multiple, equivalent CPUs dedicated to tasks such as I/O. A stack processor can be very small making it simple to add more processors to assign to time critical tasks. No need for special "accelerators" unless the task actually requires special hardware for speed beyond what a CPU can provide. Many don't see the advantage of being able to roll your own CPU which can be tailored to a task. That's why Xilinx has two ARM processors in FPGAs. Large and power hungry. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-02-08 07:15 -0800 |
| Message-ID | <2d6eded5-06dd-4385-8087-b90d66bb9720@googlegroups.com> |
| In reply to | #54719 |
> In the end I came to realize there were three execution units in the > design, the data stack/alu, the return stack/alu(for addressing and loop > control) and the instruction address/alu. It could make sense to > provide independent fields in the instruction for each of these so they > might be combined in many different ways, not unlike the CPU Hugh talks > about and others like the J1. But this complicates the compiler which > is a bit beyond my interests. I am more used to coding microcode > manually than designing tools to automate it. Many instruction coding approaches are exist. For a practical designs, it is more important to provide a toolchain and properly target domain area rather then research new cool command sets. Packed instructions are interesting but its usage should be based on the system modelling and combined hardware/software optimization. It looks too imbalanced to create a schematic and when calls to programmer without listening any feedback from him. > > For Gen5 architecture, new 6-inputs LUT are comes, and next low-cost > > FPGA Spartan-6 appears. Next important thing to improve was targeting > > LUT acrhitecture, so 6-bit command was used, with appropriate > > trade-offs. This is not 'final solution' because I don't believe in > > 'final solutions' :) > > It is hard to match instruction size to LUT inputs because there are > often other inputs such as zero detect, interrupt state, etc. That is a Excuse me... what? :) Show me the piece of code you are talking about, please. > Do you use the pipeline stages for separate threads? Rather than > filling the pipeline with multiple instructions from one thread and > flushing when the address is not linear, each phase of the pipeline is > treated as a separate thread requiring each register to have N copies. > Very little extra logic is needed and this can improve the overall > throughput because of the elimination of pipeline stalls. I can fill pipeline with new thread each cycle without penalty. > The Propeller approach is to use multiple, equivalent CPUs dedicated to > tasks such as I/O. A stack processor can be very small making it simple > to add more processors to assign to time critical tasks. No need for > special "accelerators" unless the task actually requires special > hardware for speed beyond what a CPU can provide. This is two separate tasks. Placing many CPUs may be too crude solution. Geterogenuous CPUs may be more usable. > Many don't see the advantage of being able to roll your own CPU which > can be tailored to a task. That's why Xilinx has two ARM processors in > FPGAs. Large and power hungry. This has a clear goal - to enter the ARM ecosystem. Having known CPU onchip allows to provide a complete list of ARM-related feautures, like DDR3/USB/Ethernet under Linux or bare metal. Many designers from the ARM world can be involved in this case, unlike for custom-made CPUs, which requires much higher skill to design.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-08 15:49 -0500 |
| Message-ID | <o7g04r$blr$1@dont-email.me> |
| In reply to | #54722 |
On 2/8/2017 10:15 AM, Ilya Tarasov wrote: >> In the end I came to realize there were three execution units in the >> design, the data stack/alu, the return stack/alu(for addressing and loop >> control) and the instruction address/alu. It could make sense to >> provide independent fields in the instruction for each of these so they >> might be combined in many different ways, not unlike the CPU Hugh talks >> about and others like the J1. But this complicates the compiler which >> is a bit beyond my interests. I am more used to coding microcode >> manually than designing tools to automate it. > > Many instruction coding approaches are exist. For a practical designs, it is more important to provide a toolchain and properly target domain area rather then research new cool command sets. Packed instructions are interesting but its usage should be based on the system modelling and combined hardware/software optimization. It looks too imbalanced to create a schematic and when calls to programmer without listening any feedback from him. > >>> For Gen5 architecture, new 6-inputs LUT are comes, and next low-cost >>> FPGA Spartan-6 appears. Next important thing to improve was targeting >>> LUT acrhitecture, so 6-bit command was used, with appropriate >>> trade-offs. This is not 'final solution' because I don't believe in >>> 'final solutions' :) >> >> It is hard to match instruction size to LUT inputs because there are >> often other inputs such as zero detect, interrupt state, etc. That is a > > Excuse me... what? :) Show me the piece of code you are talking about, please. Ok, show us your code for conditional jumps. That would require six inputs for the opcode and one more for the condition status, no? Like I've said before, I don't need to write VHDL to count inputs to a function. That function and its inputs must be defined before I can write one line of HDL. >> Do you use the pipeline stages for separate threads? Rather than >> filling the pipeline with multiple instructions from one thread and >> flushing when the address is not linear, each phase of the pipeline is >> treated as a separate thread requiring each register to have N copies. >> Very little extra logic is needed and this can improve the overall >> throughput because of the elimination of pipeline stalls. > > I can fill pipeline with new thread each cycle without penalty. Yes, that is what I am describing. You can have as many threads running concurrently as there are levels in your pipeline. >> The Propeller approach is to use multiple, equivalent CPUs dedicated to >> tasks such as I/O. A stack processor can be very small making it simple >> to add more processors to assign to time critical tasks. No need for >> special "accelerators" unless the task actually requires special >> hardware for speed beyond what a CPU can provide. > > This is two separate tasks. Placing many CPUs may be too crude > solution. Geterogenuous CPUs may be more usable. Was that supposed to be "Heterogeneous"? "Crude" is a value judgement without meaning. Heterogeneous CPUs are nice when needed, but require specific tools which have to be developed. It all depends on the gain vs. the cost. In general I have not found much that can be customized other than adding a few instructions like bit masks or multiplies. YMMV. >> Many don't see the advantage of being able to roll your own CPU which >> can be tailored to a task. That's why Xilinx has two ARM processors in >> FPGAs. Large and power hungry. > > This has a clear goal - to enter the ARM ecosystem. Having known CPU > onchip allows to provide a complete list of ARM-related feautures, > like DDR3/USB/Ethernet under Linux or bare metal. Many designers from > the ARM world can be involved in this case, unlike for custom-made > CPUs, which requires much higher skill to design. While the J1 was developed specifically because of the need for fast hardware which was not practical by other means. Programming the ARM by "many designers from the ARM world" means C. Are your projects in C? Adding memory does not require an ARM. Adding USB and Ethernet can be done with separate CPUs rather than an special FPGAs that limit your choices and pricing flexibility. If the ARM-FPGA combo fits your needs fine, but there are huge advantages to soft core CPUs in FPGAs. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-02-09 01:14 -0800 |
| Message-ID | <9ac7976a-e7b1-46e4-80fa-a9f758a62d7c@googlegroups.com> |
| In reply to | #54726 |
> >> It is hard to match instruction size to LUT inputs because there are > >> often other inputs such as zero detect, interrupt state, etc. That is a > > > > Excuse me... what? :) Show me the piece of code you are talking about, please. > Ok, show us your code for conditional jumps. That would require six > inputs for the opcode and one more for the condition status, no? Yes and no :) Six inputs will be mapped in LUT6, and 7th will go to F7MUX laying next to that LUT. Overall number of LUTs will be decreased if proper width of command will be chosen (inluding auxiliary signals, of course). > Like I've said before, I don't need to write VHDL to count inputs to a > function. That function and its inputs must be defined before I can > write one line of HDL. Since you miss additional logic cell resources, you can't predict real schematic. For some VHDL expressions, 7-th and 8-th inputs can be mapped to additional multiplexers which are presents in latest FPGA families. > > I can fill pipeline with new thread each cycle without penalty. > > Yes, that is what I am describing. You can have as many threads running > concurrently as there are levels in your pipeline. Why do you name it 'concurrently', if one pipeline can write one result per cycle? This is sequental, pipelined or maybe another word for designation, but not concurrent. > > This is two separate tasks. Placing many CPUs may be too crude > > solution. Geterogenuous CPUs may be more usable. > > Was that supposed to be "Heterogeneous"? "Crude" is a value judgement > without meaning. Heterogeneous CPUs are nice when needed, but require > specific tools which have to be developed. It all depends on the gain > vs. the cost. In general I have not found much that can be customized > other than adding a few instructions like bit masks or multiplies. YMMV. Wide-command, narrow command (and higher clock speed), multithreading Forth CPU. Maybe ARM (if exist) or MicroBlaze to get their world benefits. DSP engines. Specific tools are provided by Forth, isn't it? :) Forth is a very flexible and powerful language and allow to create specific languages for embedded very fast. > > This has a clear goal - to enter the ARM ecosystem. Having known CPU > > onchip allows to provide a complete list of ARM-related feautures, > > like DDR3/USB/Ethernet under Linux or bare metal. Many designers from > > the ARM world can be involved in this case, unlike for custom-made > > CPUs, which requires much higher skill to design. > > While the J1 was developed specifically because of the need for fast > hardware which was not practical by other means. Programming the ARM by > "many designers from the ARM world" means C. Are your projects in C? > Adding memory does not require an ARM. Adding USB and Ethernet can be > done with separate CPUs rather than an special FPGAs that limit your > choices and pricing flexibility. If the ARM-FPGA combo fits your needs > fine, but there are huge advantages to soft core CPUs in FPGAs. Xilinx Zynq series is good enough. There is no practical need to rewrite TCP/IP stack on Forth (however, we have limited Ethernet support for my CPUs), or to provide SD card support, if it is implemented already with known results. Forths is flexible? Ok, so let's use it for tasks which requires flexbility. Having C-based 'core' running on ARM and frequently changed firmware for Forth CPUs is a way to combine benefits from both worlds.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-09 05:19 -0500 |
| Message-ID | <o7hfk8$c0t$1@dont-email.me> |
| In reply to | #54740 |
On 2/9/2017 4:14 AM, Ilya Tarasov wrote: >>>> It is hard to match instruction size to LUT inputs because >>>> there are often other inputs such as zero detect, interrupt >>>> state, etc. That is a >>> >>> Excuse me... what? :) Show me the piece of code you are talking >>> about, please. > >> Ok, show us your code for conditional jumps. That would require >> six inputs for the opcode and one more for the condition status, >> no? > > Yes and no :) Six inputs will be mapped in LUT6, and 7th will go to > F7MUX laying next to that LUT. Overall number of LUTs will be > decreased if proper width of command will be chosen (inluding > auxiliary signals, of course). Not sure what you are saying will be decreased compared to what. Smaller instruction words will result in smaller decoding logic, that is obvious. I was addressing your point about using a 6 bit instruction because of the 6 input LUTs. My point is there are often extra inputs beyond the instruction word and so the match between LUT size and word width is not so important. Wider LUTs reduce the LUT count and narrower instructions reduce the LUT count. >> Like I've said before, I don't need to write VHDL to count inputs >> to a function. That function and its inputs must be defined before >> I can write one line of HDL. > > Since you miss additional logic cell resources, you can't predict > real schematic. For some VHDL expressions, 7-th and 8-th inputs can > be mapped to additional multiplexers which are presents in latest > FPGA families. Sure, but that still uses more resources and runs slower. The point is there is no magic about matching the width of the instruction to the LUT inputs. >>> I can fill pipeline with new thread each cycle without penalty. >> >> Yes, that is what I am describing. You can have as many threads >> running concurrently as there are levels in your pipeline. > > Why do you name it 'concurrently', if one pipeline can write one > result per cycle? This is sequental, pipelined or maybe another word > for designation, but not concurrent. The instruction streams are all running without switching a processor between tasks. Even though they run on consecutive clock cycles, they are all running on what is logically separate CPUs at the same time. >>> This is two separate tasks. Placing many CPUs may be too crude >>> solution. Geterogenuous CPUs may be more usable. >> >> Was that supposed to be "Heterogeneous"? "Crude" is a value >> judgement without meaning. Heterogeneous CPUs are nice when >> needed, but require specific tools which have to be developed. It >> all depends on the gain vs. the cost. In general I have not found >> much that can be customized other than adding a few instructions >> like bit masks or multiplies. YMMV. > > Wide-command, narrow command (and higher clock speed), multithreading > Forth CPU. Maybe ARM (if exist) or MicroBlaze to get their world > benefits. DSP engines. Specific tools are provided by Forth, isn't > it? :) Forth is a very flexible and powerful language and allow to > create specific languages for embedded very fast. > >>> This has a clear goal - to enter the ARM ecosystem. Having known >>> CPU onchip allows to provide a complete list of ARM-related >>> feautures, like DDR3/USB/Ethernet under Linux or bare metal. Many >>> designers from the ARM world can be involved in this case, unlike >>> for custom-made CPUs, which requires much higher skill to >>> design. >> >> While the J1 was developed specifically because of the need for >> fast hardware which was not practical by other means. Programming >> the ARM by "many designers from the ARM world" means C. Are your >> projects in C? Adding memory does not require an ARM. Adding USB >> and Ethernet can be done with separate CPUs rather than an special >> FPGAs that limit your choices and pricing flexibility. If the >> ARM-FPGA combo fits your needs fine, but there are huge advantages >> to soft core CPUs in FPGAs. > > Xilinx Zynq series is good enough. There is no practical need to > rewrite TCP/IP stack on Forth (however, we have limited Ethernet > support for my CPUs), or to provide SD card support, if it is > implemented already with known results. Forths is flexible? Ok, so > let's use it for tasks which requires flexbility. Having C-based > 'core' running on ARM and frequently changed firmware for Forth CPUs > is a way to combine benefits from both worlds. > -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-02-09 03:48 -0800 |
| Message-ID | <fe89858b-8e37-499c-bc72-95b0eb1cae45@googlegroups.com> |
| In reply to | #54744 |
> Sure, but that still uses more resources and runs slower. The point is > there is no magic about matching the width of the instruction to the LUT > inputs. No, you are wrong here. 'Targeting FPGA architecture' is a separate chapter in FPGA guides. You will not be slower if properly utilize logic cell resources. Missing them and giving no chance to find optimal configuration will make design slower. Utilizing more parts of logic cell (LUT is not equivalent of 'logic cell') will keep clock speed at high level because existing auxiliary resources will be involved in design. > The instruction streams are all running without switching a processor > between tasks. Even though they run on consecutive clock cycles, they > are all running on what is logically separate CPUs at the same time. This is not a description of my design. I have one CPU pipeline, but still several threads.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-05 16:08 -0500 |
| Message-ID | <o7844k$2a1$1@dont-email.me> |
| In reply to | #54632 |
On 2/4/2017 8:54 PM, Ilya Tarasov wrote: >> You mean I don't have a fully coded VHDL example at 32 bits word >> width to show you? No, I don't. But that is not needed. The >> control logic would be trivial compared to thousands of LUTs. The >> only extra logic required is on the order of a handful of adders >> and/or multiplexers. > > So you can't show me a code and utilization report, but still > claiming area will be small? How small? What about 'only extra logic' > and how you can estimate the size of adders/multiplexers for you > code? I don't need a weatherman to know which way the wind blows. I don't have to construct a design to have an estimate of how large it will be. If I need a look up table with a 10 bit address and 32 bit words, I know that will take two 16 kbit blocks of memory. If my design needs 5 - 32 bit adders, I know that will be about 160 - 4 input LUTs. If the design does a 32x32 bit multiply I know it will take 4 - 18 bit multipliers and 64 LUTs of adder (if it's using all 64 output bits otherwise fewer adder LUTs), etc., etc., etc... >> I took the time to do some calculations which show to get results >> accurate to all but the last bit of a 32 bit word would require a >> sin() table with a quarter of a million values. That would put it >> outside the realm of most FPGAs and require external memory. >> However if external memory is used, this is not only feasible but >> simple. The only issue is to get the step sizes small enough so >> the two approximations do apply, sin(b)=b and cos(b)=1.0 to within >> the required accuracy. > > Again, I don't see you 'required accuracy'. Can you list your results > and explain how you got it? How about a Forth program. Good thing I wrote this. I see I made an error in my manual calculations. This program shows a need for a 16 bit address in the LUT, not 18. Here is the code. \ calculates the number of bits needed to address the LUT \ in a DDS for a given number of output bits \ To preserve the assumption that COS(b) is ~= 1.0 the minimum step of \ COS in the LUT should be no more than one lsb. \ FPI/2 is not ANS standard, you may need to add it to your system. MARKER SINE : 2^F ( f1 -- f2 ) \ Raise 2 to a power, floating point 2.0e0 FLN F* FEXP ; : SinLUTSize ( n1 -- n2 ) \ n1 is number of bits out, n2 is LUT address bits DUP S>F 2^F 1.0e0 FSWAP F/ \ Turn bit count into resolution CR ." Required resolution " . ." bits or " FDUP F. 1.0e0 FSWAP F- FACOS FPI/2 F/ \ Resolution to phase angle step in 90 deg LUT CR ." Maximum phase angle step size in LUT " FDUP F. 1.0e0 FSWAP F/ FLN 2.0e0 FLN F/ 0.5e0 F+ F>S \ round to integer CR ." Number of bits required in LUT address " DUP . DUP S>F 2^F 1.0e0 FSWAP F/ FPI/2 F* FCOS 1.0e0 FSWAP F- CR ." Resolution with " . ." bit address " FDUP F. 1.0e0 FSWAP F/ CR ." Accuracy of 1 part in " FDUP F. ." or " FLN 2.0E0 FLN F/ F. ." bits" ; PRECISION 11 SET-PRECISION 32 SinLUTSize SET-PRECISION ****** results ****** FLOAD 'C:\Arius\Projects\Forth\SinLUTSize.f' Required resolution 32 bits or .00000000023 Maximum phase angle step size in LUT .00001373774 Number of bits required in LUT address 16 Resolution with 16 bit address .00000000029 Accuracy of 1 part in 3481368790.7 or 31.697007505 bits ok >> I've never seen an application that needed 32 bits of sin/cos. The >> DDS work I've done was related to real world signals which are >> limited to some 20 to 24 bits of SNR when converting between analog >> and digital at very best. I was pretty happy when I showed myself >> I could get 20 bits without any real trouble. > > The fact you don't need it is not a fact nobody need it. ADC > resolution matters, but this is not the only factor to choose sin/cos > resolution. Results with single precision and double-precision floats > are not the same for given ADC. Again, I can write a piece of Forth > code to show the difference... but maybe you will switch from > thinking to coding? I'm not sure what you are saying here. Single precision floats use either 24 or 25 bits of mantissa (with 1 bit hidden), I can't recall which. Either one is as good or better than the cutting edge of any ADC technology I am aware of with the exception of very high resolution, very low speed ADCs used for weight scales and such. What are you using 32 bit sine calculations for? As for thinking vs. coding, I'll take an ounce of thinking for a pound of coding any day. >>> I have several designs. Now it is 7th generation of >>> microarchitecture, with hardware multithreading, targeting >>> Spartan-6 and 7-series Xilinx FPGAs. >> >> But that doesn't tell me what a Forth CPU is. I assume you really >> mean a stack machine. When you say "hardware multithreading", I >> expect this is using the pipeline to facilitate multiple threads >> rather than concurrent instructions in a single thread? > > Yes, I really mean a stack machine, i.e. words like DUP DROP + - AND > OR are executed in one clock cycle with all appropriate modifications > to stack pointers etc. Multiple threads are supported by time > multiplexing, so one data memory and one ALU are shared between all > threads, but each clock cycle belongs to its own thread. Ok, I just wanted to be clear. I am familiar with the requirements of stack machines and have designed my own. I believe the multi-threading you refer to is implemented by using each stage in your pipeline for separate threads. An 8 stage pipeline allows 8 threads. Often this can be done without an appreciable lowering of the clock speed compared to a single thread machine. It does limit one feature in CPUs, low power by stopping the clock. All thread processors run until all threads are idle. Only then can the clock be disabled. But no biggie. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 21:59 -0500 |
| Message-ID | <o7e1fm$t9i$1@dont-email.me> |
| In reply to | #54655 |
On 2/5/2017 4:08 PM, rickman wrote: > On 2/4/2017 8:54 PM, Ilya Tarasov wrote: >>> You mean I don't have a fully coded VHDL example at 32 bits word >>> width to show you? No, I don't. But that is not needed. The >>> control logic would be trivial compared to thousands of LUTs. The >>> only extra logic required is on the order of a handful of adders >>> and/or multiplexers. >> >> So you can't show me a code and utilization report, but still >> claiming area will be small? How small? What about 'only extra logic' >> and how you can estimate the size of adders/multiplexers for you >> code? > > I don't need a weatherman to know which way the wind blows. > > I don't have to construct a design to have an estimate of how large it > will be. If I need a look up table with a 10 bit address and 32 bit > words, I know that will take two 16 kbit blocks of memory. If my design > needs 5 - 32 bit adders, I know that will be about 160 - 4 input LUTs. > If the design does a 32x32 bit multiply I know it will take 4 - 18 bit > multipliers and 64 LUTs of adder (if it's using all 64 output bits > otherwise fewer adder LUTs), etc., etc., etc... > > >>> I took the time to do some calculations which show to get results >>> accurate to all but the last bit of a 32 bit word would require a >>> sin() table with a quarter of a million values. That would put it >>> outside the realm of most FPGAs and require external memory. >>> However if external memory is used, this is not only feasible but >>> simple. The only issue is to get the step sizes small enough so >>> the two approximations do apply, sin(b)=b and cos(b)=1.0 to within >>> the required accuracy. >> >> Again, I don't see you 'required accuracy'. Can you list your results >> and explain how you got it? > > How about a Forth program. Good thing I wrote this. I see I made an > error in my manual calculations. This program shows a need for a 16 bit > address in the LUT, not 18. Here is the code. > > > \ calculates the number of bits needed to address the LUT > \ in a DDS for a given number of output bits > \ To preserve the assumption that COS(b) is ~= 1.0 the minimum step of > \ COS in the LUT should be no more than one lsb. > \ FPI/2 is not ANS standard, you may need to add it to your system. > > MARKER SINE > > : 2^F ( f1 -- f2 ) \ Raise 2 to a power, floating point > 2.0e0 FLN F* FEXP ; > > : SinLUTSize ( n1 -- n2 ) \ n1 is number of bits out, n2 is LUT address > bits > DUP S>F 2^F 1.0e0 FSWAP F/ \ Turn bit count into resolution > CR ." Required resolution " . ." bits or " FDUP F. > 1.0e0 FSWAP F- FACOS FPI/2 F/ \ Resolution to phase angle step in 90 > deg LUT > CR ." Maximum phase angle step size in LUT " FDUP F. > 1.0e0 FSWAP F/ FLN 2.0e0 FLN F/ > 0.5e0 F+ F>S \ round to integer > CR ." Number of bits required in LUT address " DUP . > DUP S>F 2^F 1.0e0 FSWAP F/ FPI/2 F* FCOS 1.0e0 FSWAP F- > CR ." Resolution with " . ." bit address " FDUP F. > 1.0e0 FSWAP F/ > CR ." Accuracy of 1 part in " FDUP F. ." or " FLN 2.0E0 FLN F/ F. ." > bits" > ; > > PRECISION 11 SET-PRECISION > > 32 SinLUTSize > > SET-PRECISION > > > > ****** results ****** > FLOAD 'C:\Arius\Projects\Forth\SinLUTSize.f' > Required resolution 32 bits or .00000000023 > Maximum phase angle step size in LUT .00001373774 > Number of bits required in LUT address 16 > Resolution with 16 bit address .00000000029 > Accuracy of 1 part in 3481368790.7 or 31.697007505 bits ok > > >>> I've never seen an application that needed 32 bits of sin/cos. The >>> DDS work I've done was related to real world signals which are >>> limited to some 20 to 24 bits of SNR when converting between analog >>> and digital at very best. I was pretty happy when I showed myself >>> I could get 20 bits without any real trouble. >> >> The fact you don't need it is not a fact nobody need it. ADC >> resolution matters, but this is not the only factor to choose sin/cos >> resolution. Results with single precision and double-precision floats >> are not the same for given ADC. Again, I can write a piece of Forth >> code to show the difference... but maybe you will switch from >> thinking to coding? > > I'm not sure what you are saying here. Single precision floats use > either 24 or 25 bits of mantissa (with 1 bit hidden), I can't recall > which. Either one is as good or better than the cutting edge of any ADC > technology I am aware of with the exception of very high resolution, > very low speed ADCs used for weight scales and such. > > What are you using 32 bit sine calculations for? > > As for thinking vs. coding, I'll take an ounce of thinking for a pound > of coding any day. > > >>>> I have several designs. Now it is 7th generation of >>>> microarchitecture, with hardware multithreading, targeting >>>> Spartan-6 and 7-series Xilinx FPGAs. >>> >>> But that doesn't tell me what a Forth CPU is. I assume you really >>> mean a stack machine. When you say "hardware multithreading", I >>> expect this is using the pipeline to facilitate multiple threads >>> rather than concurrent instructions in a single thread? >> >> Yes, I really mean a stack machine, i.e. words like DUP DROP + - AND >> OR are executed in one clock cycle with all appropriate modifications >> to stack pointers etc. Multiple threads are supported by time >> multiplexing, so one data memory and one ALU are shared between all >> threads, but each clock cycle belongs to its own thread. > > Ok, I just wanted to be clear. I am familiar with the requirements of > stack machines and have designed my own. I believe the multi-threading > you refer to is implemented by using each stage in your pipeline for > separate threads. An 8 stage pipeline allows 8 threads. Often this can > be done without an appreciable lowering of the clock speed compared to a > single thread machine. It does limit one feature in CPUs, low power by > stopping the clock. All thread processors run until all threads are > idle. Only then can the clock be disabled. But no biggie. LOL... I was discussing this in another group and I had completely forgotten what I learned about this when I did the same exercise a couple/few years ago. The determinant of the resolution is the approximation cos(b) = 1.0. In the region of zero degrees the cosine function approaches a quadratic. The slope of the curve is -x^2. So changing the required resolution by two bits requires one extra address bit. The LUT address bits will *always* be half the total phase word bits for optimum accuracy. I can't believe I forgot that. Also, the accuracy will be twice what is calculated by the program (half the error). The value out of the sine table is unsigned and a sign bit is added depending on the quadrant indicated by the phase word. So you get an extra bit and twice the accuracy compared to what my program calculated. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-28 11:10 +0100 |
| Message-ID | <o6hqm8$5q5$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54470 |
In article <o6gj07$ner$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: > > >> If you know another effective algorithm with hardware multipliers and >> exact result (not approximated), please give me a link. > >There's no such thing as "exact" digital trig solutions unless you have >an infinitely long word. What do you mean by exact? My idea has a continuously varying frequenties with 0 1e harmonic (2 *) 0 2e harmonic 0 3e harmonic 0 4e harmonic 0 5e harmonic 0 6e harmonic 0 7e harmonic 0 8e harmonic 0 9e harmonic (10 *) The zeroes are a theoretical zero assuming the digital part is exact, meaning, it assumes values of i in [1,N] i*dV which are exact. This is within reach of an MSP430. >-- > >Rick C -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-28 06:15 -0500 |
| Message-ID | <o6hucn$cc$1@dont-email.me> |
| In reply to | #54480 |
On 1/28/2017 5:10 AM, Albert van der Horst wrote: > In article <o6gj07$ner$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> >> >>> If you know another effective algorithm with hardware multipliers and >>> exact result (not approximated), please give me a link. >> >> There's no such thing as "exact" digital trig solutions unless you have >> an infinitely long word. What do you mean by exact? > > My idea has a continuously varying frequenties with > 0 1e harmonic (2 *) > 0 2e harmonic > 0 3e harmonic > 0 4e harmonic > 0 5e harmonic > 0 6e harmonic > 0 7e harmonic > 0 8e harmonic > 0 9e harmonic (10 *) > > The zeroes are a theoretical zero assuming the digital part > is exact, meaning, it assumes values of i in [1,N] i*dV > which are exact. This is within reach of an MSP430. Sorry, I don't follow. This notation does not make sense to me. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-28 19:48 +0100 |
| Message-ID | <o6ip1a$7bk$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54483 |
In article <o6hucn$cc$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 1/28/2017 5:10 AM, Albert van der Horst wrote: >> In article <o6gj07$ner$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> >>> >>>> If you know another effective algorithm with hardware multipliers and >>>> exact result (not approximated), please give me a link. >>> >>> There's no such thing as "exact" digital trig solutions unless you have >>> an infinitely long word. What do you mean by exact? >> >> My idea has a continuously varying frequenties with >> 0 1e harmonic (2 *) >> 0 2e harmonic >> 0 3e harmonic >> 0 4e harmonic >> 0 5e harmonic >> 0 6e harmonic >> 0 7e harmonic >> 0 8e harmonic >> 0 9e harmonic (10 *) >> >> The zeroes are a theoretical zero assuming the digital part >> is exact, meaning, it assumes values of i in [1,N] i*dV >> which are exact. This is within reach of an MSP430. > >Sorry, I don't follow. This notation does not make sense to me. Ok the statement is: The sine generator has a continously variable frequency. The sine generator has no distortion in the first few harmonics. > >-- > >Rick C Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-28 14:37 -0500 |
| Message-ID | <o6irq5$5si$1@dont-email.me> |
| In reply to | #54495 |
On 1/28/2017 1:48 PM, Albert van der Horst wrote: > In article <o6hucn$cc$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 1/28/2017 5:10 AM, Albert van der Horst wrote: >>> In article <o6gj07$ner$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>> >>>> >>>>> If you know another effective algorithm with hardware multipliers and >>>>> exact result (not approximated), please give me a link. >>>> >>>> There's no such thing as "exact" digital trig solutions unless you have >>>> an infinitely long word. What do you mean by exact? >>> >>> My idea has a continuously varying frequenties with >>> 0 1e harmonic (2 *) >>> 0 2e harmonic >>> 0 3e harmonic >>> 0 4e harmonic >>> 0 5e harmonic >>> 0 6e harmonic >>> 0 7e harmonic >>> 0 8e harmonic >>> 0 9e harmonic (10 *) >>> >>> The zeroes are a theoretical zero assuming the digital part >>> is exact, meaning, it assumes values of i in [1,N] i*dV >>> which are exact. This is within reach of an MSP430. >> >> Sorry, I don't follow. This notation does not make sense to me. > > Ok the statement is: > The sine generator has a continously variable frequency. > The sine generator has no distortion in the first few harmonics. Can you explain anything about how it works? When you say "within reach" of an MSP430, I'm not clear on what that means. Any processor can implement any algorithm. The issue is speed. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-01-28 07:48 -0800 |
| Message-ID | <b2d958c6-f722-44ef-89d6-6734c7858b16@googlegroups.com> |
| In reply to | #54480 |
On Saturday, January 28, 2017 at 11:10:45 AM UTC+1, Albert van der Horst wrote: [..] > My idea has a continuously varying frequenties with > 0 1e harmonic (2 *) [..] > 0 9e harmonic (10 *) > > The zeroes are a theoretical zero assuming the digital part > is exact, meaning, it assumes values of i in [1,N] i*dV > which are exact. I am very sure you know that a continuously varying signal does not have a discrete spectrum (finite set of harmonics). I guess you want a characteristic that is better described in the time-domain. What is it? -marcel
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-28 19:53 +0100 |
| Message-ID | <o6ipc4$7cr$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54489 |
In article <b2d958c6-f722-44ef-89d6-6734c7858b16@googlegroups.com>, <mhx@iae.nl> wrote: >On Saturday, January 28, 2017 at 11:10:45 AM UTC+1, Albert van der Horst wrote: >[..] >> My idea has a continuously varying frequenties with >> 0 1e harmonic (2 *) >[..] >> 0 9e harmonic (10 *) >> >> The zeroes are a theoretical zero assuming the digital part >> is exact, meaning, it assumes values of i in [1,N] i*dV >> which are exact. > >I am very sure you know that a continuously varying signal does not have a discrete spectrum (finite set of harmonics). I guess you want a characteristic that is better described in the time-domain. What is it? Please restrict lines to 72 characters. You can complain to everybody who tells what the distortion of his sine generator is, because no sine generator can be working since before the big bang. Sheez! I set my varco to arrive at 1.0101901909101901910910328723987329732978328 Khz Then I wait an infinite time to stabilize. Then I measure the harmonics. > >-marcel > Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-01-28 15:49 -0800 |
| Message-ID | <d9310bb7-6e31-452f-842e-e488a5a4a264@googlegroups.com> |
| In reply to | #54496 |
On Saturday, January 28, 2017 at 7:54:27 PM UTC+1, Albert van der Horst wrote: > In article <b2d958c6-f722-44ef-89d6-6734c7858b16@googlegroups.com>, > <mhx@iae.nl> wrote: > >On Saturday, January 28, 2017 at 11:10:45 AM UTC+1, Albert van der Horst wrote: > >[..] > >> My idea has a continuously varying frequenties with > >> 0 1e harmonic (2 *) > >[..] > >> 0 9e harmonic (10 *) > >> > >> The zeroes are a theoretical zero assuming the digital part > >> is exact, meaning, it assumes values of i in [1,N] i*dV > >> which are exact. > > > >I am very sure you know that a continuously varying signal > >does not have a discrete spectrum (finite set of harmonics). > >I guess you want a characteristic that is better described > >in the time-domain. What is it? > > Please restrict lines to 72 characters. > > You can complain to everybody who tells what the distortion of his > sine generator is, because no sine generator can be working since > before the big bang. Sheez! > Only when they claim an impossibly low distortion. But indeed, one could claim that a sine oscillator never produces a sinewave. > I set my varco to arrive at > 1.0101901909101901910910328723987329732978328 Khz > > Then I wait an infinite time to stabilize. > Then I measure the harmonics. That varco will have a drift that is no way able to keep up with the 43 decimal digits of your desired resolution. I think your wish has to do with the effect that an immediate frequency change produces a very objectionable auditory effect, not unlike a click. Old electronic organs suffered from this. Gating an oscillator has a similar problem, as does using extremely steep filters. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Wolfgang Allinger" <all2001@spambog.com> |
|---|---|
| Date | 2017-01-23 18:46 -0300 |
| Message-ID | <DuRJJ5yzQoB@allinger-307049.user.uni-berlin> |
| In reply to | #54297 |
On 23 Jan 17 at group /comp/lang/forth in article o64rhj$6sf$1@cherry.spenarnc.xs4all.nl <albert@cherry.spenarnc.xs4all.nl> (Albert van der Horst) wrote: > In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >> great? > A 50 Mhz MSP432 suggest that we will never see a fast (>> 100 Mhz) MSP430. :-( > Forthers would like to see a 1000 Mhz 6809. That too has > never happened. A 25 MHz RTX2000 is/was fun enough :) Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang -- Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt! Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p (lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.forth
csiph-web