Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: rickman Newsgroups: comp.lang.forth Subject: Re: embedded forth Date: Wed, 8 Feb 2017 06:39:10 -0500 Organization: A noiseless patient Spider Lines: 135 Message-ID: References: <49b3566a-3842-4f9f-a47f-a66590625fef@googlegroups.com> <423bc49f-f47d-415d-80d6-53fb0472c929@googlegroups.com> <7f7415ad-9ba0-4d9a-ba9d-d08fad5c344e@googlegroups.com> <92d07db1-18b7-410e-a77c-d7ab4f6606d8@googlegroups.com> <4b343d40-7252-4919-8e0d-aeace01a87cd@googlegroups.com> <5feb22db-9f9c-46df-bdc8-9ae4e14d275d@googlegroups.com> <16c24a97-fe0f-4e16-967b-6e3b058ba4e7@googlegroups.com> <15a3b0b8-fd42-4f6c-85a0-ce3acbbb9643@googlegroups.com> <16b07369-08bd-4e8a-a6b2-d91876d9451b@googlegroups.com> <0c5b0081-b02a-4fb7-9796-12f3c25a2ed6@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 8 Feb 2017 11:37:23 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="cd6920b229c8b78398c4bdf504224a30"; logging-data="15500"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19hmWTaMG7MuFcz/K3/3QwX" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <0c5b0081-b02a-4fb7-9796-12f3c25a2ed6@googlegroups.com> Cancel-Lock: sha1:ts0Yu/YHvL0QCy2YWmFngnqCujA= Xref: csiph.com comp.lang.forth:54719 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