Interesting discussion of C versus Forth in the context of the Propeller 2.
Yes, I do realized that one of Forth's primary attractions is to bootstrap devices that don't yet have a lot of other software resources yet developed. It is worthwhile in a tool kit for new CPU explorations.
I doubt I am ever going to be an innovative CPU designer, but understanding more of the ins and outs of CPU architecture would certainly make me a bit more aware of why code is the way it is.
=============
Onto the project.
A. It seems progress in being made elsewhere to successfully migrate, load, and run the Propeller 1V image in the BeMicro CVA9... so that is not going to be part of the work load here. Eventual modifications will wait until a Forth CPU in working.
B. Forth on FPGA tends to be somewhat elusive. I have publications for all sorts of projects that claimed success in various ways on FPGAs over ten years ago. But links seem to be broken and authors seem to have published much of their claims while withholding key elements of what actually is in the Verilog code.
BUT, there is at least C. H. Ting providing a FPGA solution for eForth with "complete documentation" -- the eP32.
Avoid the obstacles that it has a $39.00 USD purchase price and in Chinese. READ CAREFULLY, there appears to be a free download of the English version in what seems to be MS Word .doc format in a .zip file.
I personally am having trouble with reading it in OpenOffice. It may be the font selection, it may be written in English on a Chinese version of Windows, or it may be something else. I will try to find out if an alternative clean PDF version might be available for purchase. (I had the similar trouble with a free complete version of "eForth and Zen", so it seems to originate with whatever C.H. Ting is using for a word processor and OS.
This is going to be code for a different Altera FPGA product (not the Altera Cyclone V series E). Plus I am unsure if I would be buying a document that permits only me to use the code that is developed on that basis or something that is open to all.
I may try the Chinese version as well and hope I can follow the Verilog listings and eForth dictionary without the trying to read too much text. It this why I have studied Chinese for the past 20 years? OMG!
LOL! It seems my hopes for a complete eF32 documentation included Verilog are in a Windows .doc that is an MS Chinese font.
I did manage to globally convert the downloaded .zip text - which is a mix of English and Chinese to an Open Office document by changing the font to Droid Sans Fallback.
But it certainly isn't what I expected, and it may very well be that C. H. Ting wrote it originally in Chinese and has found no reason to spend the time to translate to English.
++++++++
Is this a job for automated translation software? I dunno. I have to reconsider all my options with where I desire to start on an FPGA Forth installation.
jmg
My world is quite insular as I am an American living in Taiwan and have been so for 20 years.
Under such circumstances, MS products have never worked well for me. English language support for those living abroad has never been good and actually all MS English language products are more expensive than the same in the USA due to their region-by-region pricing and product control.
So, I really don't have a clue about .net and have gone over to Linux where I can get online help that is much better. MS support generally starts out with [1] ask a friend or co-worker, [2] pay someone to teaching you, and only if you must [3] hire us to provide support. I don't have access to users that can adequately help me, and I don't have the funds to pay for others to do so.
While others may have good experience with MS, mine has been overall negative and costly. So I don't think I will ever return to their products. If I were to buy a proprietary OS platform at this point, it would be an Apple Computer.
++++++++
STATUS
I had hoped that I would find an easy and complete document to creating a Forth machine in FPGA. At this point, it seems that isn't the case and that I am going to have to survey all the available material and then explore piecing together a 'minimalistic CPU' that supports Forth.
That all takes time, effort, and thought. So this project may slow way down. As I have already mentioned, most of the Forth FPGA work was done over 10 years ago in what seems to be a burst of enthusiasm for FPGA devices at that time. And now the researchers have moved on to other things, except for a few.
C. H. Ting still entices me. I have to directly contact him and see what exactly is available in English. He not only offers his book on eF32 (in Chinese with charts and code in English and Verilog); there seems to be a $25 CD available that may be more English user friendly.
I am not going to bank on eF32 being the only choice. There are 16bit Forth CPUs written up from several authors. So there is more to run down, read, and think about.
++++++++++
It is still early in terms of progress. I have not yet received my FPGA purchases and Quartus II requires two updates to be ready to use. I have the distraction of working for the next few days, and that will slow matters further.
jmg
My world is quite insular as I am an American living in Taiwan and have been so for 20 years.
Under such circumstances, MS products have never worked well for me. English language support for those living abroad has never been good and actually all MS English language products are more expensive than the same in the USA due to their region-by-region pricing and product control.
So, I really don't have a clue about .net and have gone over to Linux where I can get online help that is much better. MS support generally starts out with [1] ask a friend or co-worker, [2] pay someone to teaching you, and only if you must [3] hire us to provide support. I don't have access to users that can adequately help me, and I don't have the funds to pay for others to do so.
While others may have good experience with MS, mine has been overall negative and costly. So I don't think I will ever return to their products. If I were to buy a proprietary OS platform at this point, it would be an Apple Computer.
The point I was trying to make, has nothing to do with Microsoft, but is all about byte code support.Perhaps I should have said instead Byte Codes like Java ?
Rather than trying to craft a Forth CPU from the ground up, why not take something that works very well, like the many Forth's around now, on a P1, and then
a) check and remove unused opcodes - drops LE usage to fit in smaller MAX10's for example.b) Add opcodes for the tightest inner loops, to speed up the Byte Code engine.c) Add small HW bridge to feed from QuadSPI
The result would be something that can run Forth, but also Spin, or LMM C, or LMM PropBASIC, or Java subset ?Such an optimised byte-code inner loop would also be a useful benchmark for P2.(one place to start, would be to pull in a couple of P2 opcodes, like Read and Inc )
I think Cluso already did some work on boosting Spin's inner loop on a FPGA ?
jmg,
Frankly, I don't really have a good grasp of what 'byte code support' means. Years ago, I attempted Java, but got lost in a 700 page manual while newer versions kept marching along.
For simply running Forth on an FPGA, one certainly could use something smaller... like the MAX10. But I opted to purchase the BeMicro CV and BeMicroCVA9 because I get stuck with $44USD shipping regardless of the purchase amount. Buying a $30USD device with $44USD in shipping is rather annoying.
Looking on Yahoo Taiwan, the retail vendors for Altera FPGA devices seem to have only gotten up to Cyclone iV, so the importing of a Cyclone V seemed wise. I simply have a ton of extra capacity.
+++++++++++++
:I have located a couple of links to PDFs that provide support for the design of CPUs in general on an FPGA. One is 17 pages long and a bit introductory. The other is over 200 pages long with over 100 pages of specific module code.
I already have Tachyon Forth, pfth Forth, and PropForth experience with the Propeller. So at this point, I guess curiosity got the better of me and I have 'drunk the FPGA KoolAid'.
Yes, I could merely load the Propeller 1V FPGA code or wait for Propeller 2 FPGA code... but I thought this might be an interesting independent project... to learn more on my own.
+++++++++
I did get started with the presumption that the J1 Verilog code was enough to get going in Forth on an FPGA, but I don't quite see how to incorporate a Forth dictionary into it. So I went looking for a more comprehensive example.
And I am still sorting out what might be best. It is a bit of a research project with multiple goals that are discovered along the way.
I am not a FPGA Propeller 2 developer that will take the Propeller 1-2-3 board and create supporting software. Let's just say I am an FPGA experimenter, and a beginner at that.
+++++++++++++
I'd love to know more about Byte Codes. The topic comes up often in Parallax Forums, but actually teaching of the topic seems to occur elsewhere. In other words, Parallax's education mission seems to not include the topic.
Byte codes are just machine instructions, generally for a machine that does not physically exist in hardware. The machine is virtual, that is to say the byte codes are read, interpreted and executed by a software engine. Well, as you know, we have bytecodes in Spin with the interpreter being the code running in COG at boot time. We have byte codes in Java and C# etc.
I would not even look at Java/.NET byte codes. They are actually quite complicate high level instructions, not just your simple ADD, MOV, JMP stuff.
But what about when we run Z80 instructions under an emulator like ZiCog or qZ80. All of a sudden those real machine instructions have become byte codes for the emulator VM. Similarly for the ZPU processor instruction set.
Actually, perhaps you should look at the ZPU, it has byte wide instructions, only a few of them, they are simple operations, and they are stack based. Might be a good fit for a Forth engine or at least inspire some ideas.
I would say Parallax is right to not be teaching byte codes. It's another form of assembler basic. They already have PASM on their plate
On the other hand it is a glaring omission that the Propeller byte codes are not documented officially anywhere especially as the interpreter that runs them is integral to the Propeller itself. It's a bit like selling a CPU and not publishing the instruction set details.
The P1V verilog is good to play with for several reasons:
1) it gives you exposure to the FPGA tool chain and the loading process with a known good and working processor (plus lots of folks are playing with it and can help out)
2) it is a verilog implementation of a processor architecture you already understand so you can see how it is implemented in verilog
3) you may end up with forth engines *AND* cogs plugged into a Propeller hub or a P1 COG optimized for Forth with a REALLY BIG HUB RAM for the dictionary space, or......
4)
If you are interested, I have found a multi-episode video of a college course that goes over the internal workings of the Python interpreter and the VM. Even if you aren't interested in Python, you can see how they go from source code to "compiled" bytecode through execution. I thought it was kind of cool. VMs and bytecodes are everywhere these days.
From a learner's point of view, I have felt there are a few 'black boxes' in the Propeller curriculum. They seem to be either ignored topics or 'no go' zones. It wouldn't surprise me if byte codes are at the heart of the BS2 along with a stack machine for instructions. It is something that I have suspected since learning Forth. Parallax may be a bit overly protective of the SPIN byte codes because of the BS2.
I will try to read up on byte codes elsewhere and see what I can comprehend. Tachyon Forth uses the byte codes as one of its enhancements.
+++++++++
Meanwhile the Quartus II has successfully updated to V15.02. But I had to actually dig up a Quartus II manual to determine how to actually start the software in Debian. (It has to be started from the Command Line of course.) I simply got lost in the huge pile of executables and sub-directories.
It seems to be
# ./quartus/bin/quartus
Debian 8.1 64 bit seems an installable environment even though the Altera documentation only mentions Red Hat.
++++++++
I am beginning to get a few jitters that I have gotten into more than expected with Forth on an FPGA. But we will just have to see how it works out. I can always migrate to exploring the Propeller 1V and Propeller 2 FPGA images with what I have. And at least one device might become a dedicated oscilloscope at I did purchase the BESCOPE board that is supposed to work with the BeMicroCV.
i am NOT putting my focus entirely on a Forth FPGA and Peter J has pretty much convinced me already that while interesting, the FPGA devices are more for exploring ideas than actually building a board with one included. Having a 440 pin ball gate array is not for DIY hobby boards.
I hope I will just return to the Propeller with a better appreciation of what it does and how it can be used via the knowledge gained herein.
IF you look how Peter implemented Tachyon, you see how the Forth Kernel 'primitives' map to PASM instructions.
Now if you can build a Forth-CPU where those 'primitives' are handled very efficiently by direct HW instructions or an efficient combination of those you can get a really good performance.
HW support for at least 2 stacks will help a lot, since stack operations are among the most used.
Peter implemented a ByteCode Analyser (after my very primitive start)
This shows the use of bytecodes / primitives running several different programms. https://docs.google.com/document/d/1S0GYIriDgw5uuVoYTzrbvwC9-F2qDDTkO56iN4_8YF0/pub
I will take a serious look at the Byte Codee Analyser.
Is the primary reason for Peter J to use byte codes is to provide a means to hasten the execution of code listen in the Forth dictionary in Hubram? (This is just my hunch, not something others mentioned.)
In other words, is there much to be gained by deploying byte codes as a scheme on a Forth machine with only one CPU? Or is the deployment of Tachyon's byte codes a boost to getting through the Hub's cycle?
The reason I ask is that it seems to me that with 4 bytes in a Long, each Long passes along 4 byte codes. Whereas, other schemes might pass something else that is both less complex and more difficult to process.
(I do need to glance at Tachyon again to make sure I am not getting too far afield with this.)
Tachyon Forth uses the byte codes as one of its enhancements.
Actually most of TACHYON is written in byte codes -
generated by the Tachyon compiler from Tachyon source code.
Only the Kernel itself is written in PASM and provides a kind of virtual machine which
executes the Tachyon byte codes directly.
And to make bootstrap with the Spin-Tool some basic routines are written in manualy crafted
byte code - just enough to get it running.
All to be seen in Tachyon.spin
Everything else (EXTEND ...) is pure Tachyon-Forth code compiled by the Tachyon compiler.
I run it in the background '&' so I don't tie up my terminal - maybe an old dinosaur habit these days!
+++++++++
No jitters! I've had fun just learning Verilog and wrapping my head around another way of programming - normal languages, Forth's backwardness and HDL's MASSIVE parallelism - it's all good stuff!
Whatever you come away with is going to be good stuff.
+++++++++
FPGAs and BGAs for hobbyists - maybe, maybe not. If you have a project that needs 64 pins of Propeller power, maybe a $49 (and dropping) FPGA dev board is just as useful or a better solution than a $35 QuickStart with a second Propeller stuck on top of it.
jmg,
Frankly, I don't really have a good grasp of what 'byte code support' means. ......
Yes, I could merely load the Propeller 1V FPGA code or wait for Propeller 2 FPGA code... but I thought this might be an interesting independent project... to learn more on my own.
As others have shown too, byte codes are everywhere
You can compile just one COG of a P1V, and that comes in pretty small.
Then, look at extending opcodes & Verilog to support faster inner loops of those. Some examples :
Exactly the same process can be followed for the inner loops of Tachyon, and there are likely to be large overlaps, where both Spin and Forth jump in speed.
Addit:Also found this, that looks to tabulate Spin-Bytecodes and their frequency of use.http://forums.parallax.com/discussion/comment/970536/#Comment_970536
The last one is interesting, as it looks to use CLUT memory as a fast CASE Table, that does not consume code memory.Not sure if the lastest P2 variant has the same CLUT structure, but something like a CLUT memory could be added to P1V verilog.
I will take a serious look at the Byte Codee Analyser.
Is the primary reason for Peter J to use byte codes is to provide a means to hasten the execution of code listen in the Forth dictionary in Hubram? (This is just my hunch, not something others mentioned.)
In other words, is there much to be gained by deploying byte codes as a scheme on a Forth machine with only one CPU? Or is the deployment of Tachyon's byte codes a boost to getting through the Hub's cycle?
The reason I ask is that it seems to me that with 4 bytes in a Long, each Long passes along 4 byte codes. Whereas, other schemes might pass something else that is both less complex and more difficult to process.
The byte code analyser is really just a way of working out which byte codes are being used and how many times. It was a way of optimizing the instruction set to see which codes are more important than others in terms of limited cog memory for the virtual machine. For instance there are some fast constants coded as a single byte such as 0,1,2 etc. The first few are very common and used all the time and if I had a lot more cog memory to play with I could just have a whole bunch of them but the BCA helped me to see that 3 is used more than 1 and the way that I wrote the code for the fast constants was to pack as much as possible into as little memory as possible so the code for each constant cascades into the next with a common exit to save memory but some take a fraction longer because they have to cascade all through the others as such in this listing.
{ *** FAST CONSTANTS *** }
' Push a preset literal onto the stack using just one bytecode
' Use the "accumulator" (which is always zeroed after use) to push the value which is built up by incrementing and/or decrementing
' There is a minor penalty for the larger constants but it's still faster and more compact
' overall than using the PUSH1 method or the mov X,# method
' 140606 just reordered to 1 4 2 3 according to BCA results
' 140603 new method to allow any value in any order, relies on carry being cleared in doNEXT and min will always set carry here
74D4(0075) 21 4A CF 49 | BL if_nc min ACC,#32+1 wc ' 1.4us
74D8(0076) 11 4A CF 49 | _16 if_nc min ACC,#16+1 wc
74DC(0077) 09 4A CF 49 | _8 if_nc min ACC,#8+1 wc
74E0(0078) 05 4A CF 49 | _4 if_nc min ACC,#4+1 wc ' 1.2us
74E4(0079) 03 4A CF 49 | _2 if_nc min ACC,#2+1 wc
74E8(007A) 02 4A CF 49 | _1 if_nc min ACC,#1+1 wc
74EC(007B) 04 4A CF 49 | _3 if_nc min ACC,#3+1 wc ' bytecode analysis reveals 3 is used quite heavily
74F0(007C) | _TRUE
74F0(007C) 01 4A FF 84 | MINUS1 sub ACC,#1
74F4(007D) | _FALSE
74F4(007D) 73 00 7C 5C | _0 jmp #PUSHACC ' 1us
Notice the actual cog addresses (0075) etc. These become the actual byte codes that are compiled and that "byte code" is used to directly execute the code, so there is in fact no real "interpreting", only fetching byte codes which are 8-bit addresses into 9-bit addressed cog memory. Traditional Forths use a 16 or 32-bit address but that's also because they are able to address far more machine code than a cog that can only address 512 longs in it's cog memory. In fact the opcodes of a 6502 could be considered as native "byte code", how so? Well the instruction to increment the X register is a single 8-bit byte, but the CPU fetches, increments its PC, decodes, and executes that, then repeats the cycle for the next instruction. The Tachyon virtual machine (VM) is no different in that it emulates a CPU that fetches an 8-bit opcode, increments its PC (instruction pointer), "decodes", and executes that instruction. That's also why I refer to these bytes codes as "opcodes".
Here is the "fetch/decode/execution" heart of the Tachyon VM:
7740(0110) A4 EB BF 00 | doNEXT rdbyte instr,IP 'read byte code instruction
7744(0111) 01 48 FF 81 | add IP,#1 wc 'advance IP to next byte token (clears the carry too!)
7748(0112) F5 01 3C 5C | jmp instr 'execute the code by directly indexing the first 256 long in cog
Have a look at a high level definition made up of those fast constants "byte codes":
The first byte code is 7A which is the entry address in the VM cog for 1, the next is 79 which is 2 and I did a SWAP SWAP just so that the two identical codes would stand out as 1F 1F followed by a 27 which is the address of the PLUS operation and the actual "return from subroutine" or EXIT is 0C with anything after that just temporary compilation area for when I typed ' DEMO QD. In fact you can even see a 0C in that sequence too (71 46 D8 BE BF 0C).
Now why would you want to waste four times the memory for an opcode when one byte will do? Stack machines do not require source and destination addresses in their opcodes, the Prop uses 18-bits (plus 1 immediate bit) out of its 32 just for this alone.
So there is nothing mysterious about byte codes, you can just view them as opcodes for a VM or a real CPU if you make one in FPGA!
Ever so slowly... byte codes are becoming clearer. The 'fast constants' discussion above clears up how optimization via bytecodes works in Tachyon Forth. (I was imagining all sorts of odd balls scenarios.)
Simply put, they are 8 bit op codes that point to segments of machine code, but one can use other formats (like the 5-bit op code mentioned above that is common in some Forth schemes).
So they also seem to require a jump table to actually provide the means to locate the related segments of machine codes.
And in a VM (virtual machine), these 8 bit op codes can be sent to a variety of devices with different machine code where an interpreter for the VM would make any given code do the same thing on the differing devices.
++++++++++++
STATUS....
Quartus II V15.0 (Update 2) in Debian 8.1-64bit is ready to go, but still looking for DHL to swoop down with my order of FPGAs. (DHL has promised no later than tomorrow.)
On the fast track, I will soon attempt to load the BeMicroCV with a Propeller IV FPGA image. I have much to learn about the whole Quartus II environment, Verilog, and VHDL.
In my simple minded world, I thought that Verilog and VHDL were the same thing. Apparently that is wrong-headed.
There are contrast and comparison discussions everywhere. Here is just one link to make other beginners aware.
In the slow lane, I am still trying to get my head around a first Forth project for the BeMicroCV
On the back burner, the BeMicroCVA9 seems a bit larger and others are trying to discover exactly how to use it with Parallax Propeller projects. So it may sit idle for now while others with more knowhow discover its charms.
Ever so slowly... byte codes are becoming clearer. The 'fast constants' discussion above clears up how optimization via bytecodes works in Tachyon Forth. (I was imagining all sorts of odd balls scenarios.)
Simply put, they are 8 bit op codes that point to segments of machine code, but one can use other formats (like the 5-bit op code mentioned above that is common in some Forth schemes).
So they also seem to require a jump table to actually provide the means to locate the related segments of machine codes.
And in a VM (virtual machine), these 8 bit op codes can be sent to a variety of devices with different machine code where an interpreter for the VM would make any given code do the same thing on the differing devices.
The optimization in Tachyon is that there is no jump table, the byte code is the address as in $0C is the byte code for EXIT, and at cog address $0C is the EXIT code. Hence the "fetch/decode/execute" loop doesn't even have to decode and as a result is very fast.
Spin doesn't use a jump table either but the byte code is not an address, it is decoded further and further so this slows it down too. But now you can start to understand that a byte code VM such as Tachyon could be implemented on another CPU, such as an ARM, although there are better ways if that were the case as Tachyon is custom built for the Prop. The 5-bit code is fine if you like to pack them in a longer word, say 6 to a long for instance but then it becomes more complicated to process although you can imagine a loop executing in 5 instructions quite rapidly but then again there is still a problem with alignment etc.
Okay, I can see how Tachyon has managed to use Bytecode to eliminate the Jump Table as part of the work load on the Propeller 1... rather brilliant.
+++++++++
Meanwhile...........
I am a bit dismayed as I cannot seem to reach www.forth.org from Taiwan. I have tried from multiple computers, some wifi via wifi hot spots and others at my home.
This is quite important as I finally managed to locate a copy of C. H. Ting's eP16.zip file at
www.forth.org/eP16.zip.
And this is for FPGA and all in English. It looks like the best place to start with for an FPGA Forth.
This all very odd. I downloaded ithe eP16.zip this afternoon to my Android 4.4 cell phone, and unzipped it when I found exactly the materials I had been hoping for, but that download copy seems to be stuck in the cell phone. Maybe I will get it migrated to my home desktop via USB cable -- but I am uncertain.
Will someone please try to reach www.forth.org in the USA and let us know if it is active? This seem to be the home of the original F.I.G site and I now seem to get consistent messages that it is down. It all seems very very odd that just after I located what it appears I need that the web site disappeared.
What I have on my cell phone is eP16.zip from C.H.Ting and it may be possible to buy a CD version of this at his company site - www.offete.org
Further more it appears that the English text - which is about 250 pages long is indeed a English version of the eF32 text, but adapted to 16 bit and with all the various FPGA VHDL code (not Verilog code). Personally, I have no problem if I must buy the text and code for $25 from C. H. Ting. But I am dismayed that one of the mainstay Forth sites in the world may have disappeared. I am hoping it is something of a glitch and not permanent.
www.forth.org may not actually be related to a true Forth Interest Group. The domain name is owned by Taygeta.com out of Monterey, California. I will try to contact them to see if the site has been pulled down.
Well, I am very happy to see a copy of he eP16.zip available above.
Not sure why I am shut out of www.forth.org. Could it be that their administrator imagines that I am some Chinese hacker and blocked all Taiwan traffic? I dunno.
++++++++++++++++
I did manage to migrate my one and only copy of eP16.zip from my cell phone to another computer via USB cable with copy and paste. And have opened it for reading.
The two PDFs are a complete and readable text and a Table of Contents in a separate PDF. That works fine for me.
The tutorial is rather complete and dated 2012 by C. H. Ting. And this tutorial is NOT Verilog, it is VHDL.
I have read a few times that Verilog is the most used HDL in the USA where as VHDL is the most used in Europe.
I always wondered if that is some weird cultural bias or just a happy accident. Some have said the terse "C like" syntax of Verilog suits the freedom loving yanks and that the verbose "ADA like" nature of VHDL suits the up tight English and Germans. Perhaps they are only kidding.
I like the look of VHDL more. I also like the fact that I can run VHDL code on my Linux boxes after compiling with the open source GHDL compiler.
A big gotcha with that idea is that VHDL is a very big language in which you can describe hardware that just isn't synthesizable into a working FPGA image. You have to be careful to write your code with those constraints in mind if you are developing VHDL on a PC with GHDL.
I did mention a link that compared Verilog and VHDL. It was posted today. And I read it.
It is not entirely a simple story. Verilog envisions the physical wiring, VHDL can get a bit more abstract. My only point at that time is that they were not to be confused. But the article actually included examples of Verilog, VHDL, and C applied to creating HDL for the same tasks.
+++++++++
I am extremely happy that eP16.zip is available to all. C. H. Ting's presentation is clear and the .zip file included code for the Brevia which may migrate to the BeMicroCV.
I even noticed an ep32_chip.vhd file included in the zip.. that just may be the 32bit version ;-)
I really needed and desired such a comprehensive tutorial as I likely would waste a lot of time looking for missing pieces. One needs the VHDL code example, but also need a Forth Metacompiler and other elements to pull a working whole together.
Soon I may drop an email to C. H. Ting and see what else he might have to offer. But for now, it seems adequate resources have been found.
Just found this thread. Sal is using the BE-Micro and the got the one that comes with the oscilliscope.
He has trimmed out all the P1 bits that do not get used in Propforth 5.5, and made a P1V that is tailored to Propforth. Of course we can put back in any parts we want (video driver, special register, etc) as we wish, and or add more memory, or more cogs, or increase the clock speed, or add custom hardware to do whatever else one does with FPGA. I think one of the standard configs will be 16 cogs with larger hub ram and larger cog ram.
The download for Propforth 6 will include the capability to load and test new P1V FPGA builds on suitable hardware, as well as the existing ability to load and test new kernel on the physical prop.
Its all ready to go, he just needs to make it idiot proof so I can test it. The "work" thing keeps getting it the way, but I might see the test build as early as Sunday. (Which Sunday I cannot say, but that is the story as I know it).
Just found this thread. Sal is using the BE-Micro and the got the one that comes with the oscilliscope.
He has trimmed out all the P1 bits that do not get used in Propforth 5.5, and made a P1V that is tailored to Propforth. ..... I think one of the standard configs will be 16 cogs with larger hub ram and larger cog ram.
Sounds cool.
An interesting build report would be for one forth-COG, on the MAX 10 series, as they come down in size offerings quite a long way.
Well, I am very happy to see a copy of he eP16.zip available above.
Not sure why I am shut out of www.forth.org. Could it be that their administrator imagines that I am some Chinese hacker and blocked all Taiwan traffic? I dunno.
That is a possibility. I have a computer in the cloud where I log all intrusion attempts, and when I see one originating from certain areas (from where they hammer on my system all day, every day) I block the whole segment of that ISP. All of it. Even if it's /12, or /11.. and I got the idea from elsewhere, so there must be others doing it as well. You can find blanket lists of firewall- and Apache rules for whole regions. Of course this particular computer isn't meant to be accessed by anyone else than myself and a couple of others when I'm travelling - I need a common point somewhere I can reach from where I'm travelling. So I can afford to block the whole world if I wish, commercial sites can't do this. But I can imagine that non-commercial .org domains choose to leave out potential users in the interest of reducing the hacking protection burden. Maybe in this case they're not aware of Taiwan as a region with active Forth users - I know I wasn't, until you mentioned it some time ago.
Well, it seems that living in Taiwan is going to throw a new barrier into my research on the internet. These things tend to run in trends and are not very rational.
I fired off an email to the administrator for www.forth.org and received a reply requesting that I provide an ISN to unblock.
The problem is that I use the national telecom, Chung Hwa for my ISP. They provide service where I get a dynamically provided ISN everytime I log on. It seems that all of Taiwan's national telecom service have been blocked.
It is all a bit absurd as Taiwan has one of the very few remaining active Forth Interest Groups on the planet.
Security often tends to lead to paranoid stupidity.
+++++++++
I did manage to reach www.forth.org today by logging into a free Starbucks Yahoo wifi location. That may be an adequate work around.
From what I saw, I have gotten what I most importantly desire -- the eP16.zip download. And I find it excellent, informative, and helpful. The rest of the F.I.G site is not immediately what I need.
I also fell the 'eForth and Zen' by C. H. Ting is rather important. The first Chapter can easily be skipped for those that are not into the mystical link of Forth to Zen, but the rest is very readable and directly explains eForth.
+++++++++++++
Why eForth? -- It has good tutorial material for the complete novice. It envisions a minimal Forth engine for the sake of portable code. It is not the fastest, but a very good beginner entry point. Optimized code is not easy for new learners as there are distractions of how optimizations apply to individual architectures and unusual code schemes.
Both Tachyon and PropForth has been highly customized to optimize performance on the Propeller. They both would be more difficult to begin with as a model for an FPGA Forth image.
eForth already has several VHDL code tutorials (one working model for the xilinx Brevia, another for the Altera Straix). And the code is available for both 16 and 32 bit versions with claims that a 64 bit version is easy to achieve. And of course, the people involved have worked closely with Silicon Valley F.I.G and Charles Moore. So, the history will help you avoid dead-ended past attempts.
At this point, any one that cannot reach www.forth.org can still contact C. H. Ting via www.offete.com and buy a CD with the eP16.zip material and buy a pdf of 'eForth and Zen'. So that is a second alternative. And I am pleased that all the material seems relatively recent. The oldest date of publication that I am seeing is 2010.
+++++++++
FPGA devices didn't arrive today (which is what was promised)
DHL called and wanted clarification on my 'company name' that I was a private individual.
So it seems putting one's own name in that data field on your order is important. Giving a fake name may just lead to a long-winded discussion with your local customs about not properly registering a business name with Customs.
Also, the delivery truck driver might just be driving around looking for a company sign in a residential district.
Comments
Yes, I do realized that one of Forth's primary attractions is to bootstrap devices that don't yet have a lot of other software resources yet developed. It is worthwhile in a tool kit for new CPU explorations.
I doubt I am ever going to be an innovative CPU designer, but understanding more of the ins and outs of CPU architecture would certainly make me a bit more aware of why code is the way it is.
=============
Onto the project.
A. It seems progress in being made elsewhere to successfully migrate, load, and run the Propeller 1V image in the BeMicro CVA9... so that is not going to be part of the work load here. Eventual modifications will wait until a Forth CPU in working.
B. Forth on FPGA tends to be somewhat elusive. I have publications for all sorts of projects that claimed success in various ways on FPGAs over ten years ago. But links seem to be broken and authors seem to have published much of their claims while withholding key elements of what actually is in the Verilog code.
BUT, there is at least C. H. Ting providing a FPGA solution for eForth with "complete documentation" -- the eP32.
Avoid the obstacles that it has a $39.00 USD purchase price and in Chinese. READ CAREFULLY, there appears to be a free download of the English version in what seems to be MS Word .doc format in a .zip file.
I personally am having trouble with reading it in OpenOffice. It may be the font selection, it may be written in English on a Chinese version of Windows, or it may be something else. I will try to find out if an alternative clean PDF version might be available for purchase. (I had the similar trouble with a free complete version of "eForth and Zen", so it seems to originate with whatever C.H. Ting is using for a word processor and OS.
This is going to be code for a different Altera FPGA product (not the Altera Cyclone V series E). Plus I am unsure if I would be buying a document that permits only me to use the code that is developed on that basis or something that is open to all.
Here are some good links..
http://www.readbag.com/forth-svfig-kk-08-2010-ting
http://www.offete.com/books.html
Note <<<see Item 1016 for $39.00USD (uh... written in Chinese!) plus $5 shipping and handling. BUT there appears to be an English version in .zip for FREE as well.
I may try the Chinese version as well and hope I can follow the Verilog listings and eForth dictionary without the trying to read too much text. It this why I have studied Chinese for the past 20 years? OMG!
I did manage to globally convert the downloaded .zip text - which is a mix of English and Chinese to an Open Office document by changing the font to Droid Sans Fallback.
But it certainly isn't what I expected, and it may very well be that C. H. Ting wrote it originally in Chinese and has found no reason to spend the time to translate to English.
++++++++
Is this a job for automated translation software? I dunno. I have to reconsider all my options with where I desire to start on an FPGA Forth installation.
Forth on FPGA is not coming to me easily.
Learners that are migrating toward PASM, might see Forth as an informative and useful way to break their dependency of BASIC.
I liked the Microsoft approach with .NET - they have a common, shared byte-code layer that many languages can run on.
Crafting hardware that can run only one niche language's byte-code, seems less widely useful.
My world is quite insular as I am an American living in Taiwan and have been so for 20 years.
Under such circumstances, MS products have never worked well for me. English language support for those living abroad has never been good and actually all MS English language products are more expensive than the same in the USA due to their region-by-region pricing and product control.
So, I really don't have a clue about .net and have gone over to Linux where I can get online help that is much better. MS support generally starts out with [1] ask a friend or co-worker, [2] pay someone to teaching you, and only if you must [3] hire us to provide support. I don't have access to users that can adequately help me, and I don't have the funds to pay for others to do so.
While others may have good experience with MS, mine has been overall negative and costly. So I don't think I will ever return to their products. If I were to buy a proprietary OS platform at this point, it would be an Apple Computer.
++++++++
STATUS
I had hoped that I would find an easy and complete document to creating a Forth machine in FPGA. At this point, it seems that isn't the case and that I am going to have to survey all the available material and then explore piecing together a 'minimalistic CPU' that supports Forth.
That all takes time, effort, and thought. So this project may slow way down. As I have already mentioned, most of the Forth FPGA work was done over 10 years ago in what seems to be a burst of enthusiasm for FPGA devices at that time. And now the researchers have moved on to other things, except for a few.
C. H. Ting still entices me. I have to directly contact him and see what exactly is available in English. He not only offers his book on eF32 (in Chinese with charts and code in English and Verilog); there seems to be a $25 CD available that may be more English user friendly.
I am not going to bank on eF32 being the only choice. There are 16bit Forth CPUs written up from several authors. So there is more to run down, read, and think about.
++++++++++
It is still early in terms of progress. I have not yet received my FPGA purchases and Quartus II requires two updates to be ready to use. I have the distraction of working for the next few days, and that will slow matters further.
My world is quite insular as I am an American living in Taiwan and have been so for 20 years.
Under such circumstances, MS products have never worked well for me. English language support for those living abroad has never been good and actually all MS English language products are more expensive than the same in the USA due to their region-by-region pricing and product control.
So, I really don't have a clue about .net and have gone over to Linux where I can get online help that is much better. MS support generally starts out with [1] ask a friend or co-worker, [2] pay someone to teaching you, and only if you must [3] hire us to provide support. I don't have access to users that can adequately help me, and I don't have the funds to pay for others to do so.
While others may have good experience with MS, mine has been overall negative and costly. So I don't think I will ever return to their products. If I were to buy a proprietary OS platform at this point, it would be an Apple Computer.
The point I was trying to make, has nothing to do with Microsoft, but is all about byte code support.Perhaps I should have said instead Byte Codes like Java ?
Rather than trying to craft a Forth CPU from the ground up, why not take something that works very well, like the many Forth's around now, on a P1, and then
a) check and remove unused opcodes - drops LE usage to fit in smaller MAX10's for example.b) Add opcodes for the tightest inner loops, to speed up the Byte Code engine.c) Add small HW bridge to feed from QuadSPI
The result would be something that can run Forth, but also Spin, or LMM C, or LMM PropBASIC, or Java subset ?Such an optimised byte-code inner loop would also be a useful benchmark for P2.(one place to start, would be to pull in a couple of P2 opcodes, like Read and Inc )
I think Cluso already did some work on boosting Spin's inner loop on a FPGA ?
Frankly, I don't really have a good grasp of what 'byte code support' means. Years ago, I attempted Java, but got lost in a 700 page manual while newer versions kept marching along.
For simply running Forth on an FPGA, one certainly could use something smaller... like the MAX10. But I opted to purchase the BeMicro CV and BeMicroCVA9 because I get stuck with $44USD shipping regardless of the purchase amount. Buying a $30USD device with $44USD in shipping is rather annoying.
Looking on Yahoo Taiwan, the retail vendors for Altera FPGA devices seem to have only gotten up to Cyclone iV, so the importing of a Cyclone V seemed wise. I simply have a ton of extra capacity.
+++++++++++++
:I have located a couple of links to PDFs that provide support for the design of CPUs in general on an FPGA. One is 17 pages long and a bit introductory. The other is over 200 pages long with over 100 pages of specific module code.
I already have Tachyon Forth, pfth Forth, and PropForth experience with the Propeller. So at this point, I guess curiosity got the better of me and I have 'drunk the FPGA KoolAid'.
Yes, I could merely load the Propeller 1V FPGA code or wait for Propeller 2 FPGA code... but I thought this might be an interesting independent project... to learn more on my own.
+++++++++
I did get started with the presumption that the J1 Verilog code was enough to get going in Forth on an FPGA, but I don't quite see how to incorporate a Forth dictionary into it. So I went looking for a more comprehensive example.
And I am still sorting out what might be best. It is a bit of a research project with multiple goals that are discovered along the way.
I am not a FPGA Propeller 2 developer that will take the Propeller 1-2-3 board and create supporting software. Let's just say I am an FPGA experimenter, and a beginner at that.
+++++++++++++
I'd love to know more about Byte Codes. The topic comes up often in Parallax Forums, but actually teaching of the topic seems to occur elsewhere. In other words, Parallax's education mission seems to not include the topic.
I would not even look at Java/.NET byte codes. They are actually quite complicate high level instructions, not just your simple ADD, MOV, JMP stuff.
But what about when we run Z80 instructions under an emulator like ZiCog or qZ80. All of a sudden those real machine instructions have become byte codes for the emulator VM. Similarly for the ZPU processor instruction set.
Actually, perhaps you should look at the ZPU, it has byte wide instructions, only a few of them, they are simple operations, and they are stack based. Might be a good fit for a Forth engine or at least inspire some ideas.
I would say Parallax is right to not be teaching byte codes. It's another form of assembler basic. They already have PASM on their plate
On the other hand it is a glaring omission that the Propeller byte codes are not documented officially anywhere especially as the interpreter that runs them is integral to the Propeller itself. It's a bit like selling a CPU and not publishing the instruction set details.
The P1V verilog is good to play with for several reasons:
1) it gives you exposure to the FPGA tool chain and the loading process with a known good and working processor (plus lots of folks are playing with it and can help out)
2) it is a verilog implementation of a processor architecture you already understand so you can see how it is implemented in verilog
3) you may end up with forth engines *AND* cogs plugged into a Propeller hub or a P1 COG optimized for Forth with a REALLY BIG HUB RAM for the dictionary space, or......
4)
If you are interested, I have found a multi-episode video of a college course that goes over the internal workings of the Python interpreter and the VM. Even if you aren't interested in Python, you can see how they go from source code to "compiled" bytecode through execution. I thought it was kind of cool. VMs and bytecodes are everywhere these days.
I will try to read up on byte codes elsewhere and see what I can comprehend. Tachyon Forth uses the byte codes as one of its enhancements.
+++++++++
Meanwhile the Quartus II has successfully updated to V15.02. But I had to actually dig up a Quartus II manual to determine how to actually start the software in Debian. (It has to be started from the Command Line of course.) I simply got lost in the huge pile of executables and sub-directories.
It seems to be
# ./quartus/bin/quartus
Debian 8.1 64 bit seems an installable environment even though the Altera documentation only mentions Red Hat.
++++++++
I am beginning to get a few jitters that I have gotten into more than expected with Forth on an FPGA. But we will just have to see how it works out. I can always migrate to exploring the Propeller 1V and Propeller 2 FPGA images with what I have. And at least one device might become a dedicated oscilloscope at I did purchase the BESCOPE board that is supposed to work with the BeMicroCV.
i am NOT putting my focus entirely on a Forth FPGA and Peter J has pretty much convinced me already that while interesting, the FPGA devices are more for exploring ideas than actually building a board with one included. Having a 440 pin ball gate array is not for DIY hobby boards.
I hope I will just return to the Propeller with a better appreciation of what it does and how it can be used via the knowledge gained herein.
Now if you can build a Forth-CPU where those 'primitives' are handled very efficiently by direct HW instructions or an efficient combination of those you can get a really good performance.
HW support for at least 2 stacks will help a lot, since stack operations are among the most used.
Peter implemented a ByteCode Analyser (after my very primitive start)
This shows the use of bytecodes / primitives running several different programms.
https://docs.google.com/document/d/1S0GYIriDgw5uuVoYTzrbvwC9-F2qDDTkO56iN4_8YF0/pub
Is the primary reason for Peter J to use byte codes is to provide a means to hasten the execution of code listen in the Forth dictionary in Hubram? (This is just my hunch, not something others mentioned.)
In other words, is there much to be gained by deploying byte codes as a scheme on a Forth machine with only one CPU? Or is the deployment of Tachyon's byte codes a boost to getting through the Hub's cycle?
The reason I ask is that it seems to me that with 4 bytes in a Long, each Long passes along 4 byte codes. Whereas, other schemes might pass something else that is both less complex and more difficult to process.
(I do need to glance at Tachyon again to make sure I am not getting too far afield with this.)
Actually most of TACHYON is written in byte codes -
generated by the Tachyon compiler from Tachyon source code.
Only the Kernel itself is written in PASM and provides a kind of virtual machine which
executes the Tachyon byte codes directly.
And to make bootstrap with the Spin-Tool some basic routines are written in manualy crafted
byte code - just enough to get it running.
All to be seen in Tachyon.spin
Everything else (EXTEND ...) is pure Tachyon-Forth code compiled by the Tachyon compiler.
[rapost@toshi ~]$ which quartus
~/altera/15.0/quartus/bin/quartus
This is where Quartus chose to install itself
To run it, I do this:
[rapost@toshi ~]$ quartus &
[1] 12112
[rapost@toshi ~]$
I run it in the background '&' so I don't tie up my terminal - maybe an old dinosaur habit these days!
+++++++++
No jitters! I've had fun just learning Verilog and wrapping my head around another way of programming - normal languages, Forth's backwardness and HDL's MASSIVE parallelism - it's all good stuff!
Whatever you come away with is going to be good stuff.
+++++++++
FPGAs and BGAs for hobbyists - maybe, maybe not. If you have a project that needs 64 pins of Propeller power, maybe a $49 (and dropping) FPGA dev board is just as useful or a better solution than a $35 QuickStart with a second Propeller stuck on top of it.
Frankly, I don't really have a good grasp of what 'byte code support' means. ......
Yes, I could merely load the Propeller 1V FPGA code or wait for Propeller 2 FPGA code... but I thought this might be an interesting independent project... to learn more on my own.
As others have shown too, byte codes are everywhere
You can compile just one COG of a P1V, and that comes in pretty small.
Then, look at extending opcodes & Verilog to support faster inner loops of those. Some examples :
Google found the work Cluso did here, on a faster P1V Spin
http://forums.parallax.com/discussion/160754/new-unscrambled-p1v-rom-with-faster-spin-interpreter
and some good work is here
http://forums.parallax.com/discussion/160616/fast-spin-exeucition-a-verilog-coding-challenge
and here
http://forums.parallax.com/discussion/157766/boosting-spin-performance/p1
Exactly the same process can be followed for the inner loops of Tachyon, and there are likely to be large overlaps, where both Spin and Forth jump in speed.
Addit:Also found this, that looks to tabulate Spin-Bytecodes and their frequency of use.http://forums.parallax.com/discussion/comment/970536/#Comment_970536
and also this, which is work on a P2-focused Bytecode Execution Engine (but can give a guide for what useful opcodes to add to a P1V)http://forums.parallax.com/discussion/144599/announcing-p2bee-propeller-2-bytecode-execution-engine
The last one is interesting, as it looks to use CLUT memory as a fast CASE Table, that does not consume code memory.Not sure if the lastest P2 variant has the same CLUT structure, but something like a CLUT memory could be added to P1V verilog.
I will take a serious look at the Byte Codee Analyser.
Is the primary reason for Peter J to use byte codes is to provide a means to hasten the execution of code listen in the Forth dictionary in Hubram? (This is just my hunch, not something others mentioned.)
In other words, is there much to be gained by deploying byte codes as a scheme on a Forth machine with only one CPU? Or is the deployment of Tachyon's byte codes a boost to getting through the Hub's cycle?
The reason I ask is that it seems to me that with 4 bytes in a Long, each Long passes along 4 byte codes. Whereas, other schemes might pass something else that is both less complex and more difficult to process.
The byte code analyser is really just a way of working out which byte codes are being used and how many times. It was a way of optimizing the instruction set to see which codes are more important than others in terms of limited cog memory for the virtual machine. For instance there are some fast constants coded as a single byte such as 0,1,2 etc. The first few are very common and used all the time and if I had a lot more cog memory to play with I could just have a whole bunch of them but the BCA helped me to see that 3 is used more than 1 and the way that I wrote the code for the fast constants was to pack as much as possible into as little memory as possible so the code for each constant cascades into the next with a common exit to save memory but some take a fraction longer because they have to cascade all through the others as such in this listing.
{ *** FAST CONSTANTS *** } ' Push a preset literal onto the stack using just one bytecode ' Use the "accumulator" (which is always zeroed after use) to push the value which is built up by incrementing and/or decrementing ' There is a minor penalty for the larger constants but it's still faster and more compact ' overall than using the PUSH1 method or the mov X,# method ' 140606 just reordered to 1 4 2 3 according to BCA results ' 140603 new method to allow any value in any order, relies on carry being cleared in doNEXT and min will always set carry here 74D4(0075) 21 4A CF 49 | BL if_nc min ACC,#32+1 wc ' 1.4us 74D8(0076) 11 4A CF 49 | _16 if_nc min ACC,#16+1 wc 74DC(0077) 09 4A CF 49 | _8 if_nc min ACC,#8+1 wc 74E0(0078) 05 4A CF 49 | _4 if_nc min ACC,#4+1 wc ' 1.2us 74E4(0079) 03 4A CF 49 | _2 if_nc min ACC,#2+1 wc 74E8(007A) 02 4A CF 49 | _1 if_nc min ACC,#1+1 wc 74EC(007B) 04 4A CF 49 | _3 if_nc min ACC,#3+1 wc ' bytecode analysis reveals 3 is used quite heavily 74F0(007C) | _TRUE 74F0(007C) 01 4A FF 84 | MINUS1 sub ACC,#1 74F4(007D) | _FALSE 74F4(007D) 73 00 7C 5C | _0 jmp #PUSHACC ' 1usNotice the actual cog addresses (0075) etc. These become the actual byte codes that are compiled and that "byte code" is used to directly execute the code, so there is in fact no real "interpreting", only fetching byte codes which are 8-bit addresses into 9-bit addressed cog memory. Traditional Forths use a 16 or 32-bit address but that's also because they are able to address far more machine code than a cog that can only address 512 longs in it's cog memory. In fact the opcodes of a 6502 could be considered as native "byte code", how so? Well the instruction to increment the X register is a single 8-bit byte, but the CPU fetches, increments its PC, decodes, and executes that, then repeats the cycle for the next instruction. The Tachyon virtual machine (VM) is no different in that it emulates a CPU that fetches an 8-bit opcode, increments its PC (instruction pointer), "decodes", and executes that instruction. That's also why I refer to these bytes codes as "opcodes".Here is the "fetch/decode/execution" heart of the Tachyon VM:
Have a look at a high level definition made up of those fast constants "byte codes":
The first byte code is 7A which is the entry address in the VM cog for 1, the next is 79 which is 2 and I did a SWAP SWAP just so that the two identical codes would stand out as 1F 1F followed by a 27 which is the address of the PLUS operation and the actual "return from subroutine" or EXIT is 0C with anything after that just temporary compilation area for when I typed ' DEMO QD. In fact you can even see a 0C in that sequence too (71 46 D8 BE BF 0C).
Now why would you want to waste four times the memory for an opcode when one byte will do? Stack machines do not require source and destination addresses in their opcodes, the Prop uses 18-bits (plus 1 immediate bit) out of its 32 just for this alone.
So there is nothing mysterious about byte codes, you can just view them as opcodes for a VM or a real CPU if you make one in FPGA!
Simply put, they are 8 bit op codes that point to segments of machine code, but one can use other formats (like the 5-bit op code mentioned above that is common in some Forth schemes).
So they also seem to require a jump table to actually provide the means to locate the related segments of machine codes.
And in a VM (virtual machine), these 8 bit op codes can be sent to a variety of devices with different machine code where an interpreter for the VM would make any given code do the same thing on the differing devices.
++++++++++++
STATUS....
Quartus II V15.0 (Update 2) in Debian 8.1-64bit is ready to go, but still looking for DHL to swoop down with my order of FPGAs. (DHL has promised no later than tomorrow.)
On the fast track, I will soon attempt to load the BeMicroCV with a Propeller IV FPGA image. I have much to learn about the whole Quartus II environment, Verilog, and VHDL.
In my simple minded world, I thought that Verilog and VHDL were the same thing. Apparently that is wrong-headed.
There are contrast and comparison discussions everywhere. Here is just one link to make other beginners aware.
http://www.angelfire.com/in/rajesh52/verilogvhdl.html
In the slow lane, I am still trying to get my head around a first Forth project for the BeMicroCV
On the back burner, the BeMicroCVA9 seems a bit larger and others are trying to discover exactly how to use it with Parallax Propeller projects. So it may sit idle for now while others with more knowhow discover its charms.
Simply put, they are 8 bit op codes that point to segments of machine code, but one can use other formats (like the 5-bit op code mentioned above that is common in some Forth schemes).
So they also seem to require a jump table to actually provide the means to locate the related segments of machine codes.
And in a VM (virtual machine), these 8 bit op codes can be sent to a variety of devices with different machine code where an interpreter for the VM would make any given code do the same thing on the differing devices.
The optimization in Tachyon is that there is no jump table, the byte code is the address as in $0C is the byte code for EXIT, and at cog address $0C is the EXIT code. Hence the "fetch/decode/execute" loop doesn't even have to decode and as a result is very fast.
Spin doesn't use a jump table either but the byte code is not an address, it is decoded further and further so this slows it down too. But now you can start to understand that a byte code VM such as Tachyon could be implemented on another CPU, such as an ARM, although there are better ways if that were the case as Tachyon is custom built for the Prop. The 5-bit code is fine if you like to pack them in a longer word, say 6 to a long for instance but then it becomes more complicated to process although you can imagine a loop executing in 5 instructions quite rapidly but then again there is still a problem with alignment etc.
+++++++++
Meanwhile...........
I am a bit dismayed as I cannot seem to reach www.forth.org from Taiwan. I have tried from multiple computers, some wifi via wifi hot spots and others at my home.
This is quite important as I finally managed to locate a copy of C. H. Ting's eP16.zip file at
www.forth.org/eP16.zip.
And this is for FPGA and all in English. It looks like the best place to start with for an FPGA Forth.
This all very odd. I downloaded ithe eP16.zip this afternoon to my Android 4.4 cell phone, and unzipped it when I found exactly the materials I had been hoping for, but that download copy seems to be stuck in the cell phone. Maybe I will get it migrated to my home desktop via USB cable -- but I am uncertain.
Will someone please try to reach www.forth.org in the USA and let us know if it is active? This seem to be the home of the original F.I.G site and I now seem to get consistent messages that it is down. It all seems very very odd that just after I located what it appears I need that the web site disappeared.
What I have on my cell phone is eP16.zip from C.H.Ting and it may be possible to buy a CD version of this at his company site - www.offete.org
Further more it appears that the English text - which is about 250 pages long is indeed a English version of the eF32 text, but adapted to 16 bit and with all the various FPGA VHDL code (not Verilog code). Personally, I have no problem if I must buy the text and code for $25 from C. H. Ting. But I am dismayed that one of the mainstay Forth sites in the world may have disappeared. I am hoping it is something of a glitch and not permanent.
I wouldn't call that being pulled down. I don't know why you can't access it from Taiwan but it works fine from good old Ohio, USA!!
Not sure why I am shut out of www.forth.org. Could it be that their administrator imagines that I am some Chinese hacker and blocked all Taiwan traffic? I dunno.
++++++++++++++++
I did manage to migrate my one and only copy of eP16.zip from my cell phone to another computer via USB cable with copy and paste. And have opened it for reading.
The two PDFs are a complete and readable text and a Table of Contents in a separate PDF. That works fine for me.
The tutorial is rather complete and dated 2012 by C. H. Ting. And this tutorial is NOT Verilog, it is VHDL.
I always wondered if that is some weird cultural bias or just a happy accident. Some have said the terse "C like" syntax of Verilog suits the freedom loving yanks and that the verbose "ADA like" nature of VHDL suits the up tight English and Germans. Perhaps they are only kidding.
I like the look of VHDL more. I also like the fact that I can run VHDL code on my Linux boxes after compiling with the open source GHDL compiler.
A big gotcha with that idea is that VHDL is a very big language in which you can describe hardware that just isn't synthesizable into a working FPGA image. You have to be careful to write your code with those constraints in mind if you are developing VHDL on a PC with GHDL.
It is not entirely a simple story. Verilog envisions the physical wiring, VHDL can get a bit more abstract. My only point at that time is that they were not to be confused. But the article actually included examples of Verilog, VHDL, and C applied to creating HDL for the same tasks.
+++++++++
I am extremely happy that eP16.zip is available to all. C. H. Ting's presentation is clear and the .zip file included code for the Brevia which may migrate to the BeMicroCV.
I even noticed an ep32_chip.vhd file included in the zip.. that just may be the 32bit version ;-)
I really needed and desired such a comprehensive tutorial as I likely would waste a lot of time looking for missing pieces. One needs the VHDL code example, but also need a Forth Metacompiler and other elements to pull a working whole together.
Soon I may drop an email to C. H. Ting and see what else he might have to offer. But for now, it seems adequate resources have been found.
He has trimmed out all the P1 bits that do not get used in Propforth 5.5, and made a P1V that is tailored to Propforth. Of course we can put back in any parts we want (video driver, special register, etc) as we wish, and or add more memory, or more cogs, or increase the clock speed, or add custom hardware to do whatever else one does with FPGA. I think one of the standard configs will be 16 cogs with larger hub ram and larger cog ram.
The download for Propforth 6 will include the capability to load and test new P1V FPGA builds on suitable hardware, as well as the existing ability to load and test new kernel on the physical prop.
Its all ready to go, he just needs to make it idiot proof so I can test it. The "work" thing keeps getting it the way, but I might see the test build as early as Sunday. (Which Sunday I cannot say, but that is the story as I know it).
He has trimmed out all the P1 bits that do not get used in Propforth 5.5, and made a P1V that is tailored to Propforth. ..... I think one of the standard configs will be 16 cogs with larger hub ram and larger cog ram.
Sounds cool.
An interesting build report would be for one forth-COG, on the MAX 10 series, as they come down in size offerings quite a long way.
Not sure why I am shut out of www.forth.org. Could it be that their administrator imagines that I am some Chinese hacker and blocked all Taiwan traffic? I dunno.
That is a possibility. I have a computer in the cloud where I log all intrusion attempts, and when I see one originating from certain areas (from where they hammer on my system all day, every day) I block the whole segment of that ISP. All of it. Even if it's /12, or /11.. and I got the idea from elsewhere, so there must be others doing it as well. You can find blanket lists of firewall- and Apache rules for whole regions. Of course this particular computer isn't meant to be accessed by anyone else than myself and a couple of others when I'm travelling - I need a common point somewhere I can reach from where I'm travelling. So I can afford to block the whole world if I wish, commercial sites can't do this. But I can imagine that non-commercial .org domains choose to leave out potential users in the interest of reducing the hacking protection burden. Maybe in this case they're not aware of Taiwan as a region with active Forth users - I know I wasn't, until you mentioned it some time ago.
I fired off an email to the administrator for www.forth.org and received a reply requesting that I provide an ISN to unblock.
The problem is that I use the national telecom, Chung Hwa for my ISP. They provide service where I get a dynamically provided ISN everytime I log on. It seems that all of Taiwan's national telecom service have been blocked.
It is all a bit absurd as Taiwan has one of the very few remaining active Forth Interest Groups on the planet.
Security often tends to lead to paranoid stupidity.
+++++++++
I did manage to reach www.forth.org today by logging into a free Starbucks Yahoo wifi location. That may be an adequate work around.
From what I saw, I have gotten what I most importantly desire -- the eP16.zip download. And I find it excellent, informative, and helpful. The rest of the F.I.G site is not immediately what I need.
I also fell the 'eForth and Zen' by C. H. Ting is rather important. The first Chapter can easily be skipped for those that are not into the mystical link of Forth to Zen, but the rest is very readable and directly explains eForth.
+++++++++++++
Why eForth? -- It has good tutorial material for the complete novice. It envisions a minimal Forth engine for the sake of portable code. It is not the fastest, but a very good beginner entry point. Optimized code is not easy for new learners as there are distractions of how optimizations apply to individual architectures and unusual code schemes.
Both Tachyon and PropForth has been highly customized to optimize performance on the Propeller. They both would be more difficult to begin with as a model for an FPGA Forth image.
eForth already has several VHDL code tutorials (one working model for the xilinx Brevia, another for the Altera Straix). And the code is available for both 16 and 32 bit versions with claims that a 64 bit version is easy to achieve. And of course, the people involved have worked closely with Silicon Valley F.I.G and Charles Moore. So, the history will help you avoid dead-ended past attempts.
At this point, any one that cannot reach www.forth.org can still contact C. H. Ting via www.offete.com and buy a CD with the eP16.zip material and buy a pdf of 'eForth and Zen'. So that is a second alternative. And I am pleased that all the material seems relatively recent. The oldest date of publication that I am seeing is 2010.
+++++++++
FPGA devices didn't arrive today (which is what was promised)
DHL called and wanted clarification on my 'company name' that I was a private individual.
So it seems putting one's own name in that data field on your order is important. Giving a fake name may just lead to a long-winded discussion with your local customs about not properly registering a business name with Customs.
Also, the delivery truck driver might just be driving around looking for a company sign in a residential district.