This cannot be true, or if it is it's totally useless. What it says is that I can access memory or the stack, which is memory anyway. I can move data around but I cannot do any manipulations on it, like arithmetic or logical operations.
You misunderstand, once you have the three, YOU can write your own functions using WHATEVER THE CPU SUPPORTS. All functions are yours now. This is all the power of assembler, just easier to code.
Worse still it says I cannot make decisions or create loops.
Again, you've gotten is backwards, you can do EVERYTHING in the most efficient way the CPU supports.
Worse still it does not allow me to give names to a bunch of instructions,. I cannot define my own words. And that I thought was a big thing in Forth.
Again, you can implement the dictionary in any way the makes the most sense for your processor and application. But in this case, nobody will do the work for you (Unless you find somebody like Sal who was going to do it anyway and decides to share).
The "Standard" is more like this: We use the character + to represent the assembler ADD function. The way + works is we put two numbers A and B on the stack, and after we call the + the top two numbers are no longer on the stack, and the new top number is A+B. And so on for each assembler function we want to implement in forth, then we use these to extend the dictionary in whatever direction.
If you don't want to implement a particular assembler function as a forth word, that's your own business. For example, Sal only implemented unsigned math in the initial kernel, since that was all he needed at the time. He used that kernel to generate a development kernel which does support signed math. He used that kernels to generate a new development kernel that has all the I/O optimized to insanely fast. Code for one of these kernels is NOT compatible with another of these kernels. They are all propforth, and they are all used for their particular function in every version of propforth, every time the kernel is generated.
No. Clearly the Propeller, and other machines, have no built in stack handling hardware.
Its been a while since I looked, but I thought the cog memory was accessible as if it were a bunch of registers. So we can get at the locations and values in one instruction or something. We can change the stack size by adjusting the pointer, and there is no impact in speed. accessing any stack item takes exactly the same time. Maybe I got this wrong, I don't do the kernel stuff, but I thought the prop looked like it was designed to run forth.
They bundle the board and a chip, quantity one is OK. $34 I'm thinking to give this a try.
I already have all ten chips spoken for, but now it looks like ordering direct from these guys will be cheaper and faster (or at least less strain on me).
I had offered to solder the chips for a couple folks, how are we going to work that out now? PM me with suggestions, requests, and demands.
Peter's stack implementation in Tachyon is pretty cool. He also added a third stack - not standard but a good idea. It's been a while since I looked at the guts of PropForth so I don't remember it's implementation.
Polyforth is free for the Green Arrays chip, it is included in the download of ArrayForth along with eForth. BTW both Poly and eForth need external SRAM to run.
While I consider myself a novice. I was wondering what one can do with so many really tiny forth processors.
Then it hit me.
Just as Heater suggest, one should think about the GA chip as a bunch of fairly complex gate array blocks.
1. The simplest would be simple logic gates to
2. more complex things like counters and the like.
3. Maybe thing like data converters, ASCII to decimal or hex.
4. Control state machines.
5. CRC generator.
6. Possibly trig functions.
Hopefully each function can be done within the ROM/RAM constraints.
@ rod - Thanks for the links, google did not find those for me, and I was looking in wrong places.
@ Duane - I actually don't have a clue what one can do with these, that's one reason why I want to see a "group think" on this.
I think it can be used for processing large data streams on the fly, like DSP and imaging, but read the materials quite awhile ago and don't remember well. I do know that forth can be big boost out of single processors, for example multitasking 16 users on a single 286 or 386 PC was not a problem, aside from lugging all the ADM and VT100 terminals around. So 144 cores ought to be fun.
One of the app notes looks cool:
AP003: SRAM Control Cluster, Mark 1 (Last updated 8/10/2011) Four nodes provide a versatile but simple interface to external SRAM that may be shared by several masters, such as our virtual machines.
If I read this right, and it can do 100 billion operations per second, I would want to figure out something that need 100 billion operations per second, just to see if it cooks itself. .
A Forth engine can be embedded in a FPGA and used as a co-processor as in the case of Gameduino, which is accessible to users.
A Forth or stack CPU is also quite easy to create in a FPGA. There are many of them implemented in VHDL out there. Offete Enterprises has a few on it's website.
I don't think you are way off-base at all. The question doesn't seem to be "What can it do?" but "How fast can it do it?" I doubt it will access external memory as fast as a CMOS 6502. The lightning-fast execution of each node is largely squandered in an inefficient ad-hoc cooperation scheme with other nodes.
...once you have the three, YOU can write your own functions using WHATEVER THE CPU SUPPORTS. All functions are yours now. This is all the power of assembler, just easier to code...
And there we have it. If you have those three operations you do not have Forth, or any kind of HLL. You are still working in assembler or even numeric instruction codes.
I do get that idea. The fact that the Forth approach makes it easier to "boostrap" your self into a higher level language starting from a machine that may have no language support at all initially.
That boostrap problem is interesting. What if you had a modern Intel processor but no software at all, not even BIOS, and you wanted a C compiler for it? And what if you had no other machine to develop that C compiler on. You would be down there entering instructions via swithches and LEDs until you got something running that could be used to make program entry easier, you might use that to write a debug monitor, you might use that to write an assembler, you might use that to write your C compiler. Could take a while:)
Any way, I don't recall any mention of assembler in "Starting Forth".
And there we have it. If you have those three operations you do not have Forth, or any kind of HLL. You are still working in assembler or even numeric instruction codes.
Once you have coded the first three words in assembler, you can more quickly code the rest of the support for a basic interpreter, from there code a as full a forth as you need, and them code something like OS development tools. The idea being that its 10x fast working up through the forth tools chain than starting from scratch and coding the whole thing in assembler.
Starting Forth is about Starting. Assembler is is more advanced and beyond the scope of the beginner. but after you finish the book, you are (usually) no longer a beginner.
If you get stuck on the details of when an implementation becomes a "real forth" rather than "when it does what I want", you may be thinking about it wrong way around. That's ok, Forth is not for everyone, some folks just "don't get it". Not everyone will use every possible tool.
"How fast can it do it?" I doubt it will access external memory as fast as a CMOS 6502. The lightning-fast execution of each node is largely squandered in an inefficient ad-hoc cooperation scheme with other nodes.
I think the efficiency of the cooperation is up to the user. We just have to work out a good way to use whats there (as always).
I don't see where you are getting you opinion of speed for accessing external memory. Would this be dependent on how fast it can flip the IO pins?
Forth or stack CPU is also quite easy to create in a FPGA.
This always appeared too expensive. I never could get samples, and somebody how could design a CPU and knows forth to start this.
$8 for the prop was pushing the budget at the time, now $10 for a ga144 is little excessive but doable.
If there's and FPGA rig out there for $14 ...
I don't see where you are getting your opinion of speed for accessing external memory. Would this be dependent on how fast it can flip the IO pins?
Just think through the process of asserting a simple 14-bit address by 14 different processors, each providing a single bit. The coordination of such an event is woefully inefficient as compared with a simple hardware counter.
One thing that MUST be kept in mind is that this is NOT an FPGA. Each logic element in an FPGA is always active....it is just a piece of hardware. OTOH, a GA node is a sequential execution unit. One of the first things pointed out in any HDL tutorial is that, despite the similarities between HDL (such as Verilog) and a programming language (like C), when you write a line of HDL, you are describing something that always 'is', not something that will happen when the program counter gets back around to it.
I fear I'm still not making myself clear. But it's the best I can do at the moment.
That boostrap problem is interesting. What if you had a modern Intel processor but no software at all, not even BIOS, and you wanted a C compiler for it? And what if you had no other machine to develop that C compiler on. You would be down there entering instructions via swithches and LEDs until you got something running that could be used to make program entry easier, you might use that to write a debug monitor, you might use that to write an assembler, you might use that to write your C compiler. Could take a while:)
Here's a document describing just that process: http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html
"Bootstrapping a simple compiler from nothing" by E.G. Evans
(It bypasses the switches though and starts with hex code - and some more steps are bypassed in a description for the reader to follow)
So soorrry, but SOME of those ColorForth links seem to be broken. Maybe it is because I am in Taiwan, but I can't tell. I was able to download the Linux image, seems to be no DOS and no Windows.
They bundle the board and a chip, quantity one is OK. $34 I'm thinking to give this a try.
I already have all ten chips spoken for, but now it looks like ordering direct from these guys will be cheaper and faster (or at least less strain on me).
I had offered to solder the chips for a couple folks, how are we going to work that out now? PM me with suggestions, requests, and demands.
Hmmmm.... I was suspecting it might come to this. Schmart Boards is having a promotion that offers free shipping for over $80 US (or 3 of these), http://www.schmartboard.com/index.asp?page=products but the $35 is below that. Some people may want to go together for Schmart Boards and the savings on shipping may be a trade off with ordering direct in 10x quantify from Green Arrays. And apparently Schmart Boards is selling complete populated Propeller boards right now.
GreenArray's price of 10x for $200 definitely does NOT include shipping and that cost remains TBD (all sales FOB Incline Village, NV).
I can easily mail a check on an American bank for $60 plus shipping to you and onward to Taiwan (lets say another $20), but that might take 10 days unless I spend another $20 on two-day air delivery. If you have 10 order without me, just go ahead as I may hold up the parade.
Lots of choices to pull people in their direction.
I will hang back until people decide not to order the 10x order as my pulling out 3 chips might pull apart the whole scheme. I can just as easily order from Schmart Board, though I do suspect I can find a similar board in Taiwan.
Besides, it you really are unsure about Forth on parallel processing, you can use the Propeller Forth to get going.
The beauty of the GA144 is the F18A Forth machine as hardware. Just reading and rereading the Green Array documentation clairifies a whole bunch of details about Forth. Instead of a virtual machine, you have a wonderful presentation of what is 'the architecture' of Forth -- two stacks and an ALU work very well together. Other hardware just adapts to mimic this and the fundamental instructions to get Forth running.
Does anybody else here accept the idea that there are 3 architectures - Harvard, Von Neumann, and Forth two-stack?
While I consider myself a novice. I was wondering what one can do with so many really tiny forth processors.
Then it hit me.
Just as Heater suggest, one should think about the GA chip as a bunch of fairly complex gate array blocks.
1. The simplest would be simple logic gates to
2. more complex things like counters and the like.
3. Maybe thing like data converters, ASCII to decimal or hex.
4. Control state machines.
5. CRC generator.
6. Possibly trig functions.
Hopefully each function can be done within the ROM/RAM constraints.
Am I way off base in my thinking here?
Duane J
You are a bit ahead of me, but appear to be on the right track. I am just trying to get my head around the idea of loading 144 ROMs and then booting the whole thing without it getting 'mental' and refusing to communicate.
Edge processors have a lot of special uses (there is a PDF with a poster), while the inside ones are generic F18A processors. And Edge processors have less links to other processors - usually 3, but the corners have only 2. The interior ones have a left, right, up, and down communications channel.
Nonetheless, this is a very charming puzzle. Loads of fun.
There is an SPI interface that would likely be critical to getting this done.
I supposed the easiest approach would be to have each of the 144 ROM images (or 143 if you use the SPI node for boot loader) as a concantenated lump of code.
But the more I think about it, you are going to have to alternate between building pathways to each ROM and then loading that particular ROM. So the SPI EEPROM would have to alternate between ROM images and traffic control. It might be easier to have two EEPROMs. One with ROM node images, and a second with traffic control of loading. That would make revisions of ROMs a bit more pleasant.
A better way might be for all ROMs to be loaded with a temporary loading image, and then the true target images would be inserted by writing over those as you back out of the matrix. The matrix is 18x8, not 12x12 - and that should be considered.
I guess RAM would have to be wiped clean along the way, maybe more than once.
Excellent link to bootstrapping a compiler from nothing, thanks.
Starting from HEX is OK in my book, that's what we did for the 6809 back in the day because we had a PROM programmer available.
Mind you, we did not get past the debug monitor stage.
It's interesting that this chip is referred to as a forth chip. The basic F18 core is really nothing more than a stack-based machine. The assembly language looks like forth, and the higher level language support is forth. So I guess that's what makes it a forth chip. However, the same approach could be applied to any processor. And there's no reason you couldn't run Spin or C on this chip.
Creating a assembly language that looks like Forth, Pascal, Java or Modula-2 has been done before. It's actually straightforward. Phil Coopman's book Stack Machines describes several examples such as the MISC 16. Nicklaus Wirth created a microcoded computer that was like Modula-2. Someone in San Diego created a Pascal microengine. IMS there was a hardware implementation of Smalltalk.
Yes one could create a C or Spin to Forth translator for the FA18, but at this stage where everybody is still learning about the chip it's not worth speculating how effective such a approach would be. When I look at the chip, it screams ' FPGA floor planning ' to me. This isn't your typical CPU. You really have to plan out how to allocate resources and processors.
How are you going to run C or Spin on a core with only a handful of memory words / registers?
I am amazed to find that compiling C to in COG code for the Prop works and can actually be useful.
This chips cores are an order of magnitude smaller again.
Yes, program memory in each core is tiny, so it's better to program them in the native forth-sembly language. However, I think one of the cores can read external RAM and execute larger programs. Why else would one even bother with full-blown forth if it didn't have that capability. So my point is that you could compile C or Spin to forth-sembly language, and run it on the core that executes code from external memory.
Creating a assembly language that looks like Forth, Pascal, Java or Modula-2 has been done before. It's actually straightforward. Phil Coopman's book Stack Machines describes several examples such as the MISC 16. Nicklaus Wirth created a microcoded computer that was like Modula-2. Someone in San Diego created a Pascal microengine. IMS there was a hardware implementation of Smalltalk.
Yes one could create a C or Spin to Forth translator for the FA18, but at this stage where everybody is still learning about the chip it's not worth speculating how effective such a approach would be. When I look at the chip, it screams ' FPGA floor planning ' to me. This isn't your typical CPU. You really have to plan out how to allocate resources and processors.
Well, the more I look into it, the more interesting this gets.
eForth has a version of Forth ready that is Free and operates in merely 5 nodes on the GA144. So you have a rather large playground to explore via eForth. There are something like 23 nodes on the edges that are for i/o. And 5 or 6 for booting options. That is also a great relief as the more I read about boot loading 144 nodes, the more the task seems both daunting and amusing. Also, it seems that ROM is exactly what it says - so maybe not access to it. Nodes have to be be programmed into one of three personalities, the ROOT that sends out intialization data that is acquired from an external EEPROM or an asynchronous connection, WIRES that pass on data through intermediate nodes, and END that loads the data.
I suspect there is the Big Question in the back of other people's minds (as there has been in my own) whether just trying to use the chip without the benefit of the $450USD demo board is feasible. But the more I read, the better this looks. Sure, the demo board has USB ports and offers level shifters from 1.8volts to higher voltages for breadboarding, and not one, but two GA144 chips and it offers outside storage of substantial amount; but one can do this nicely with the Schmart Board, a tiny 1.8v power supply from Schmart or Polollu, and an Rs232 level shifting interface to connect to a dumb terminal (after using an XP or other Windows in Hyperterminal to upload resident eForth).
At least that is what I think I am reading.
@Heater
Don't be so bah humbug. This is really a rarity. There are actually two rather innovative levels of architecture. The FA18A is the processor device as dreamed up by the founder of Forth himself - likely from a personal wish list, and then there the architecture of the 18X8 tiny Forth machines to exploit in a rather vast fashion with SPI, Serial ports, Parallel Ports, ADC, and DAC. Also, I haven't read the PDF yet, but it appears one can make clocks or at least oscillators. There are references to counters being doable as well.
BTW, don't be too concerned about 18bit architecture. It seems that eForth just decide to provide a 16bit Forth within the 18bit F18A nodes with each of the five serving a dedicated task.
I like it. I guess the ZPU architecture is a "forth-sembly" machine as well, what with being stack based. And it satisfies all my "where is the real Forth" questions.
Loopy,
Don't be so bah humbug.
Perhaps you are right. It's the same "bah humbug", I had years ago, when I skipped over the Propeller in the ELFA catalog, only later to realize this crazy chip might actually be usefull:)
Okay, more reporting back what investigations of documents reveal.
1. This GA144 needs an SRAM chip to become fully supported by available developmental software - either a special release of PolyForth (very classy proprietary software) or eForth.
2. The SPI interface seems to be intended to attach to an SDcard for Flash storage.
3. There is a zip file of a scheme for making an SRAM board that will work, but it might be enhanced by an update in design. The zip file included Gerber files ready for ordering a production run. But before anything is ordering, It might be best to think about improving the design to attach easily to a Schmart Board.
4. Adding a RS232 level shifter scheme to any SRAM board and an overall power scheme would make life so much easier. Also, have it socket a Parallax microSDcard carried board. Why bother with putting this together with loose pieces when one Schmartz board, and one support board might really make one smile?
Meanwhile, it is a good time to get into Prop Forth 5.0. I built a dumb terminal just for that and got distracted.
Ok, I've been checking on this between other duties.
It looks like we don't need to make a bulk order, we can just buy the schmart board as a one off for $34. So I no longer think I need to do the 10 chip orders from Green Arrays.
I spoke with Sal, and he points out that forth on the GA144 is more like MICROCODE on other chips. (!). So we are not going to be using this to replace our propchips in a servo application..... More likely, we will need to add processing to alleviate a bottle neck in for example a vision system, we would use a GA144 on that bottle neck.
Sal is looking into the details. This part had always been out of reach due to cost, the $34 schmart board brings it within reach. BUT we still have to figure out what were going to do with it once we have it.
For the time being, I'm going to hold off buying this. I'm going to wait on guidance from Sal as to how one might properly use this part, and wait till support is in place to do that.
Tius is still in the queue, I'm thinking it will be part of the main path around xmas(?) or so.
Thanks, Prof. Braino.
Yes, the GA144 is rather challenging to recognize an actual use. I suspect a clue is the DAC and ADC interfaces. High speed 16 bit parallel i/o may make this all attractive to capture and store bursts of data.
I am looking at adding SRAM. SDcard slot, RS232, power supply and a bank of level shifters to bring the i/o to higher voltages from the 1.8v -- maybe a dual option of +3.3 and +5.0 volts.
With shipping and handling extra, buying 10 chips direct from Green Array may not be any cheaper than buying single units from Schmart Board with the board as you are going to have to pay for the Schmart Board shipping even if it came without a chip. Also, there was the implicit cost of having you reship the order to group buyers. Lots of opportunity for vague hidden costs and people actually paying more for the group buy.
As for myself, I may work up an order for Propeller boards and the GA144 package (with added power board from Schmart Board to save on costs. Over $80USD is free shipping in the US, over $150 is a 10% discount and the 5 or 10 packs look handy to have on hand.
I've read the documentation for the GA144 and the F18A several times and it is very informative as to what a Forth machine can be, but with PropForth available for 8 cogs and even supported on the Spinnerette for a mere $56 USD in a very feature rich board (SDcard, RTC, ethernet, etc), I am working to learn Forth on a Propeller first.
I now have both PropForth and Tachyon Forth running on Propeller Proto Boards, and today I managed to get multiple cogs funcitioning in PropForth. So I am making progress.
Above all, Forth is quite fun as I don't have to use an IDE and all the related proceedures to learn what the Propeller is doing. I tried a simple time delay of 3 seconds and got immediate confirmation that it was working.
If people will just try it, Forth on the Prop can be much more interactive, less tedious that Spin, PASM, or C. You can always transfer what you learn to those other languages if you want.
Comments
write your own forth interpreter http://www.bradrodriguez.com/papers/moving1.htm
the formal overblown standard (those guys are a little out of hand sometimes) http://lars.nocrew.org/dpans/dpans.htm
You misunderstand, once you have the three, YOU can write your own functions using WHATEVER THE CPU SUPPORTS. All functions are yours now. This is all the power of assembler, just easier to code.
Again, you've gotten is backwards, you can do EVERYTHING in the most efficient way the CPU supports.
Again, you can implement the dictionary in any way the makes the most sense for your processor and application. But in this case, nobody will do the work for you (Unless you find somebody like Sal who was going to do it anyway and decides to share).
The "Standard" is more like this: We use the character + to represent the assembler ADD function. The way + works is we put two numbers A and B on the stack, and after we call the + the top two numbers are no longer on the stack, and the new top number is A+B. And so on for each assembler function we want to implement in forth, then we use these to extend the dictionary in whatever direction.
If you don't want to implement a particular assembler function as a forth word, that's your own business. For example, Sal only implemented unsigned math in the initial kernel, since that was all he needed at the time. He used that kernel to generate a development kernel which does support signed math. He used that kernels to generate a new development kernel that has all the I/O optimized to insanely fast. Code for one of these kernels is NOT compatible with another of these kernels. They are all propforth, and they are all used for their particular function in every version of propforth, every time the kernel is generated.
Its been a while since I looked, but I thought the cog memory was accessible as if it were a bunch of registers. So we can get at the locations and values in one instruction or something. We can change the stack size by adjusting the pointer, and there is no impact in speed. accessing any stack item takes exactly the same time. Maybe I got this wrong, I don't do the kernel stuff, but I thought the prop looked like it was designed to run forth.
http://www.greenarraychips.com/home/products/
Then I was reminded of the schmart boards $9.99
http://www.schmartboard.com/index.asp?page=products_partnum&id=490
And finally after Loopy's post, I notice these guys are selling a board and the chip together $34
http://www.schmartboard.com/index.asp?page=products_csp&id=532
They bundle the board and a chip, quantity one is OK. $34 I'm thinking to give this a try.
I already have all ten chips spoken for, but now it looks like ordering direct from these guys will be cheaper and faster (or at least less strain on me).
I had offered to solder the chips for a couple folks, how are we going to work that out now? PM me with suggestions, requests, and demands.
Link:
ArrayForth
http://www.greenarraychips.com/home/support/download-02a.html
ArrayForth, Polyforth Documents are here DB004, DB005 and DB006
http://www.greenarraychips.com/home/documents/downindex.html
Get the SRAM pdf while you're at it, you'll need it.
While I consider myself a novice. I was wondering what one can do with so many really tiny forth processors.
Then it hit me.
Just as Heater suggest, one should think about the GA chip as a bunch of fairly complex gate array blocks.
1. The simplest would be simple logic gates to
2. more complex things like counters and the like.
3. Maybe thing like data converters, ASCII to decimal or hex.
4. Control state machines.
5. CRC generator.
6. Possibly trig functions.
Hopefully each function can be done within the ROM/RAM constraints.
Am I way off base in my thinking here?
Duane J
@ Duane - I actually don't have a clue what one can do with these, that's one reason why I want to see a "group think" on this.
I think it can be used for processing large data streams on the fly, like DSP and imaging, but read the materials quite awhile ago and don't remember well. I do know that forth can be big boost out of single processors, for example multitasking 16 users on a single 286 or 386 PC was not a problem, aside from lugging all the ADM and VT100 terminals around. So 144 cores ought to be fun.
One of the app notes looks cool:
AP003: SRAM Control Cluster, Mark 1 (Last updated 8/10/2011) Four nodes provide a versatile but simple interface to external SRAM that may be shared by several masters, such as our virtual machines.
If I read this right, and it can do 100 billion operations per second, I would want to figure out something that need 100 billion operations per second, just to see if it cooks itself. .
A Forth or stack CPU is also quite easy to create in a FPGA. There are many of them implemented in VHDL out there. Offete Enterprises has a few on it's website.
And there we have it. If you have those three operations you do not have Forth, or any kind of HLL. You are still working in assembler or even numeric instruction codes.
I do get that idea. The fact that the Forth approach makes it easier to "boostrap" your self into a higher level language starting from a machine that may have no language support at all initially.
That boostrap problem is interesting. What if you had a modern Intel processor but no software at all, not even BIOS, and you wanted a C compiler for it? And what if you had no other machine to develop that C compiler on. You would be down there entering instructions via swithches and LEDs until you got something running that could be used to make program entry easier, you might use that to write a debug monitor, you might use that to write an assembler, you might use that to write your C compiler. Could take a while:)
Any way, I don't recall any mention of assembler in "Starting Forth".
Once you have coded the first three words in assembler, you can more quickly code the rest of the support for a basic interpreter, from there code a as full a forth as you need, and them code something like OS development tools. The idea being that its 10x fast working up through the forth tools chain than starting from scratch and coding the whole thing in assembler.
Starting Forth is about Starting. Assembler is is more advanced and beyond the scope of the beginner. but after you finish the book, you are (usually) no longer a beginner.
If you get stuck on the details of when an implementation becomes a "real forth" rather than "when it does what I want", you may be thinking about it wrong way around. That's ok, Forth is not for everyone, some folks just "don't get it". Not everyone will use every possible tool.
I think the efficiency of the cooperation is up to the user. We just have to work out a good way to use whats there (as always).
I don't see where you are getting you opinion of speed for accessing external memory. Would this be dependent on how fast it can flip the IO pins?
This always appeared too expensive. I never could get samples, and somebody how could design a CPU and knows forth to start this.
$8 for the prop was pushing the budget at the time, now $10 for a ga144 is little excessive but doable.
If there's and FPGA rig out there for $14 ...
One thing that MUST be kept in mind is that this is NOT an FPGA. Each logic element in an FPGA is always active....it is just a piece of hardware. OTOH, a GA node is a sequential execution unit. One of the first things pointed out in any HDL tutorial is that, despite the similarities between HDL (such as Verilog) and a programming language (like C), when you write a line of HDL, you are describing something that always 'is', not something that will happen when the program counter gets back around to it.
I fear I'm still not making myself clear. But it's the best I can do at the moment.
"Bootstrapping a simple compiler from nothing" by E.G. Evans
(It bypasses the switches though and starts with hex code - and some more steps are bypassed in a description for the reader to follow)
(Got the link from a post over on 6502.org)
-Tor
Hmmmm.... I was suspecting it might come to this. Schmart Boards is having a promotion that offers free shipping for over $80 US (or 3 of these), http://www.schmartboard.com/index.asp?page=products but the $35 is below that. Some people may want to go together for Schmart Boards and the savings on shipping may be a trade off with ordering direct in 10x quantify from Green Arrays. And apparently Schmart Boards is selling complete populated Propeller boards right now.
GreenArray's price of 10x for $200 definitely does NOT include shipping and that cost remains TBD (all sales FOB Incline Village, NV).
I can easily mail a check on an American bank for $60 plus shipping to you and onward to Taiwan (lets say another $20), but that might take 10 days unless I spend another $20 on two-day air delivery. If you have 10 order without me, just go ahead as I may hold up the parade.
http://www.schmartboard.com/index.asp?page=products_propeller
Lots of choices to pull people in their direction.
I will hang back until people decide not to order the 10x order as my pulling out 3 chips might pull apart the whole scheme. I can just as easily order from Schmart Board, though I do suspect I can find a similar board in Taiwan.
Besides, it you really are unsure about Forth on parallel processing, you can use the Propeller Forth to get going.
The beauty of the GA144 is the F18A Forth machine as hardware. Just reading and rereading the Green Array documentation clairifies a whole bunch of details about Forth. Instead of a virtual machine, you have a wonderful presentation of what is 'the architecture' of Forth -- two stacks and an ALU work very well together. Other hardware just adapts to mimic this and the fundamental instructions to get Forth running.
Does anybody else here accept the idea that there are 3 architectures - Harvard, Von Neumann, and Forth two-stack?
You are a bit ahead of me, but appear to be on the right track. I am just trying to get my head around the idea of loading 144 ROMs and then booting the whole thing without it getting 'mental' and refusing to communicate.
Edge processors have a lot of special uses (there is a PDF with a poster), while the inside ones are generic F18A processors. And Edge processors have less links to other processors - usually 3, but the corners have only 2. The interior ones have a left, right, up, and down communications channel.
Nonetheless, this is a very charming puzzle. Loads of fun.
There is an SPI interface that would likely be critical to getting this done.
I supposed the easiest approach would be to have each of the 144 ROM images (or 143 if you use the SPI node for boot loader) as a concantenated lump of code.
But the more I think about it, you are going to have to alternate between building pathways to each ROM and then loading that particular ROM. So the SPI EEPROM would have to alternate between ROM images and traffic control. It might be easier to have two EEPROMs. One with ROM node images, and a second with traffic control of loading. That would make revisions of ROMs a bit more pleasant.
A better way might be for all ROMs to be loaded with a temporary loading image, and then the true target images would be inserted by writing over those as you back out of the matrix. The matrix is 18x8, not 12x12 - and that should be considered.
I guess RAM would have to be wiped clean along the way, maybe more than once.
Think, think, think.
Excellent link to bootstrapping a compiler from nothing, thanks.
Starting from HEX is OK in my book, that's what we did for the 6809 back in the day because we had a PROM programmer available.
Mind you, we did not get past the debug monitor stage.
I am amazed to find that compiling C to in COG code for the Prop works and can actually be useful.
This chips cores are an order of magnitude smaller again.
Maybe someone will write a SPIN interpreter in forth.
Creating a assembly language that looks like Forth, Pascal, Java or Modula-2 has been done before. It's actually straightforward. Phil Coopman's book Stack Machines describes several examples such as the MISC 16. Nicklaus Wirth created a microcoded computer that was like Modula-2. Someone in San Diego created a Pascal microengine. IMS there was a hardware implementation of Smalltalk.
Phil's book
http://www.ece.cmu.edu/~koopman/stack_computers/
Yes one could create a C or Spin to Forth translator for the FA18, but at this stage where everybody is still learning about the chip it's not worth speculating how effective such a approach would be. When I look at the chip, it screams ' FPGA floor planning ' to me. This isn't your typical CPU. You really have to plan out how to allocate resources and processors.
Well, the more I look into it, the more interesting this gets.
eForth has a version of Forth ready that is Free and operates in merely 5 nodes on the GA144. So you have a rather large playground to explore via eForth. There are something like 23 nodes on the edges that are for i/o. And 5 or 6 for booting options. That is also a great relief as the more I read about boot loading 144 nodes, the more the task seems both daunting and amusing. Also, it seems that ROM is exactly what it says - so maybe not access to it. Nodes have to be be programmed into one of three personalities, the ROOT that sends out intialization data that is acquired from an external EEPROM or an asynchronous connection, WIRES that pass on data through intermediate nodes, and END that loads the data.
I suspect there is the Big Question in the back of other people's minds (as there has been in my own) whether just trying to use the chip without the benefit of the $450USD demo board is feasible. But the more I read, the better this looks. Sure, the demo board has USB ports and offers level shifters from 1.8volts to higher voltages for breadboarding, and not one, but two GA144 chips and it offers outside storage of substantial amount; but one can do this nicely with the Schmart Board, a tiny 1.8v power supply from Schmart or Polollu, and an Rs232 level shifting interface to connect to a dumb terminal (after using an XP or other Windows in Hyperterminal to upload resident eForth).
At least that is what I think I am reading.
@Heater
Don't be so bah humbug. This is really a rarity. There are actually two rather innovative levels of architecture. The FA18A is the processor device as dreamed up by the founder of Forth himself - likely from a personal wish list, and then there the architecture of the 18X8 tiny Forth machines to exploit in a rather vast fashion with SPI, Serial ports, Parallel Ports, ADC, and DAC. Also, I haven't read the PDF yet, but it appears one can make clocks or at least oscillators. There are references to counters being doable as well.
BTW, don't be too concerned about 18bit architecture. It seems that eForth just decide to provide a 16bit Forth within the 18bit F18A nodes with each of the five serving a dedicated task.
I like it. I guess the ZPU architecture is a "forth-sembly" machine as well, what with being stack based. And it satisfies all my "where is the real Forth" questions.
Loopy,
Perhaps you are right. It's the same "bah humbug", I had years ago, when I skipped over the Propeller in the ELFA catalog, only later to realize this crazy chip might actually be usefull:)
1. This GA144 needs an SRAM chip to become fully supported by available developmental software - either a special release of PolyForth (very classy proprietary software) or eForth.
2. The SPI interface seems to be intended to attach to an SDcard for Flash storage.
3. There is a zip file of a scheme for making an SRAM board that will work, but it might be enhanced by an update in design. The zip file included Gerber files ready for ordering a production run. But before anything is ordering, It might be best to think about improving the design to attach easily to a Schmart Board.
4. Adding a RS232 level shifter scheme to any SRAM board and an overall power scheme would make life so much easier. Also, have it socket a Parallax microSDcard carried board. Why bother with putting this together with loose pieces when one Schmartz board, and one support board might really make one smile?
Meanwhile, it is a good time to get into Prop Forth 5.0. I built a dumb terminal just for that and got distracted.
It looks like we don't need to make a bulk order, we can just buy the schmart board as a one off for $34. So I no longer think I need to do the 10 chip orders from Green Arrays.
I spoke with Sal, and he points out that forth on the GA144 is more like MICROCODE on other chips. (!). So we are not going to be using this to replace our propchips in a servo application..... More likely, we will need to add processing to alleviate a bottle neck in for example a vision system, we would use a GA144 on that bottle neck.
Sal is looking into the details. This part had always been out of reach due to cost, the $34 schmart board brings it within reach. BUT we still have to figure out what were going to do with it once we have it.
For the time being, I'm going to hold off buying this. I'm going to wait on guidance from Sal as to how one might properly use this part, and wait till support is in place to do that.
Tius is still in the queue, I'm thinking it will be part of the main path around xmas(?) or so.
Yes, the GA144 is rather challenging to recognize an actual use. I suspect a clue is the DAC and ADC interfaces. High speed 16 bit parallel i/o may make this all attractive to capture and store bursts of data.
I am looking at adding SRAM. SDcard slot, RS232, power supply and a bank of level shifters to bring the i/o to higher voltages from the 1.8v -- maybe a dual option of +3.3 and +5.0 volts.
With shipping and handling extra, buying 10 chips direct from Green Array may not be any cheaper than buying single units from Schmart Board with the board as you are going to have to pay for the Schmart Board shipping even if it came without a chip. Also, there was the implicit cost of having you reship the order to group buyers. Lots of opportunity for vague hidden costs and people actually paying more for the group buy.
As for myself, I may work up an order for Propeller boards and the GA144 package (with added power board from Schmart Board to save on costs. Over $80USD is free shipping in the US, over $150 is a 10% discount and the 5 or 10 packs look handy to have on hand.
I've read the documentation for the GA144 and the F18A several times and it is very informative as to what a Forth machine can be, but with PropForth available for 8 cogs and even supported on the Spinnerette for a mere $56 USD in a very feature rich board (SDcard, RTC, ethernet, etc), I am working to learn Forth on a Propeller first.
I now have both PropForth and Tachyon Forth running on Propeller Proto Boards, and today I managed to get multiple cogs funcitioning in PropForth. So I am making progress.
Above all, Forth is quite fun as I don't have to use an IDE and all the related proceedures to learn what the Propeller is doing. I tried a simple time delay of 3 seconds and got immediate confirmation that it was working.
If people will just try it, Forth on the Prop can be much more interactive, less tedious that Spin, PASM, or C. You can always transfer what you learn to those other languages if you want.