I thought it would be a few more years until I heard someone say 8 cores wasn't enough
Actually...8 cores is shamefully short of where we should be now.
When I first started working with microprocessors professionally, in 1980, we only had single core machines. They were 8 bits and they had interrupts. Think 8085, Z80, 6809.
It was already clear to us that we did not actually want interrupts. What we wanted more "cores" (There was no such term at the time). So we built solutions with many of those 8 bit processors just so we could get the jobs done.
Now, we already had "Moore's law" predicting that the number of transistors we can put on a chip will probably double every two years.
Great, so we can have two cores instead of one in 1982. And four cores in 1984....this is going to be fantastic. We can shrink the size and cost of our solutions dramatically as time goes on.
So, by my reckoning Gordon Moore promised us, in 2014, after 34 years of process shrinks, the grand total of 131,072 cores to play with today!
OK. Where are they? What happened? What the hell has Chip been doing all this time?
Of course we did get our 100,000 times more transistors on a chip and we did get speeds up to 4GHz or whatever. But those Intel i7 and the like are pretty useless for deterministic real-time work.
Even if Heater did manage to make a C program that met the challenge...
You know, this is really annoying.
There is no possible way, with my limited time and mental capacity and total disinterest in the idea and a billion other more interesting things I want to do instead, that I am ever going to study the FAT32 file system enough to be able to write a file system driver for it. Never mind the underlying SD card block driver. Sad but true.
So, I hereby concede defeat. I am totally convinced that Peter with Tachyon and no doubt others with their brands of Forth can do that in less space and faster than any C code I will ever write to do the same.
It is now obvious to me, by virtue of my resounding defeat in this simple challenge, that all those misguided users of Spin and C and whatever so called "high level languages" should desist in their folly and switch over to Forth.
PASM programmers are likewise having it to easy and should use the much more tortuous Forth as well.
....Mean while. Peter never did show us his version of the Fast Fourier Transform in Forth for the Propeller...I really like to see it because my effort at an FFT in Forth failed miserably. No, seriously.
Chris, Actually...8 cores is shamefully short of where we should be now. When I first started working with microprocessors professionally, in 1980, we only had single core machines. They were 8 bits and they had interrupts. Think 8085, Z80, 6809.
It was already clear to us that we did not actually want interrupts. What we wanted more "cores" (There was no such term at the time). So we built solutions with many of those 8 bit processors just so we could get the jobs done.
Heater,
I am by no means new to the game. :nerd: In 1982 I was programming the 6502 in assembly on both the Apple and VIC-20 platforms. In 1985 I learned about the Z80 but didn't get into it until 1990 or so and used it until 2000 in commercial controllers. By 1988 I had also tasted 6800 and by 1990 the 68000 which I already had via my C= Amigas.
I am by no means new to the game. :nerd: In 1982 I was programming the 6502 in assembly on both the Apple and VIC-20 platforms. In 1985 I learned about the Z80 but didn't get into it until 1990 or so and used it until 2000 in commercial controllers. By 1988 I had also tasted 6800 and by 1990 the 68000 which I already had via my C= Amigas.
Hey, I finally have you beat at something! I was programming a Monrobot XI in junior high school in 1966 or thereabouts! :-)
However, that was nothing like programming micro controllers. One thing I really like about the work I've done on the Propeller and to a lesser extent on other MCUs is that I have to really think about how I'm going to fit a large application into the relatively small space and resources of an MCU. Programming desktop PCs doesn't give that satisfaction since you essentially have unlimited resources. I'm afraid MCUs are going in that direction too. I wonder what the next step will be where we have to make use of our skills at optimizing our use of resources? I kind of wonder what a P1 made with current processes would be like with 128 cores and some sort of 3D connection topology? Probably crazy but it would be fun like the current Propeller is fun. No matter what I say about the features of other chips, the Propeller is the only one I enjoy programming and keep coming back to.
I wonder what the next step will be where we have to make use of our skills at optimizing our use of resources?
Strangely enough we have now come to the point where Moores Law is running out of steam. We are not going to see those huge increases in CPU speed we have become used to over decades. At the top end if you want to get more computing done, ie FLOPS, you are going to have to go more parallel.
But, perhaps partly because of that road block, there is now a big push downwards going on. Mobile computing, wareable computing, the Internet of Things, a processor in every light bulb or LED.
Down there they want low power, which means slow clocks, small processors and not much memory.
Oddly enough down there the arguments of the interrupt supporters win out over multiple cores. The power constraints dictate the minimum of transistors in the same way that they dictated the minimum number of vacuum tubes back in the day.
For sure there is a lot of opportunities for people who want to optimize things in the IoT world.
...
So, I hereby concede defeat. I am totally convinced that Peter with Tachyon and no doubt others with their brands of Forth can do that in less space and faster than any C code I will ever write to do the same. ...
I think this probably says more about your C skills than it says about any supposed advantages Forth may have over C.
Sorry for jumping in here, but the definition of 'interrupt', as I was taught in 1986, is "any condition or change of state that causes the processor to alter its code execution path or working variable set in response to that change".
Using that definition, I see many instances of the Propeller using interrupts: SPI CS pins, toggling an I2C SCL/SCK pin, the RESn and BOEn pins, et cetera.
There is no possible way, with my limited time and mental capacity and total disinterest in the idea and a billion other more interesting things I want to do instead, that I am ever going to study the FAT32 file system enough to be able to write a file system driver for it. Never mind the underlying SD card block driver. Sad but true.
So, I hereby concede defeat. I am totally convinced that Peter with Tachyon and no doubt others with their brands of Forth can do that in less space and faster than any C code I will ever write to do the same.
It is now obvious to me, by virtue of my resounding defeat in this simple challenge, that all those misguided users of Spin and C and whatever so called "high level languages" should desist in their folly and switch over to Forth.
PASM programmers are likewise having it to easy and should use the much more tortuous Forth as well.
....Mean while. Peter never did show us his version of the Fast Fourier Transform in Forth for the Propeller...I really like to see it because my effort at an FFT in Forth failed miserably. No, seriously.
I wouldn't worry too much about what get's said, I am not impressed by those kinds of postings, it's almost trolling and plus there is nothing magical about any implementation, it's what gets done that's important (and also how much fun it is).
The trouble with Forth (but also a plus) is that it's not really a compiler, not in your C sense anyway as I know that a compiler doesn't just take a line of code and compile fixed known code, it also identifies and optimises structures too and a whole lot more. So Forth is said to compile code but since for every word of Forth you can be sure that it has compiled just that it is not much different to an assembler, albeit a high-level macroassembler, which is also why we can have specialized code optimized just right (or just plain wrong too). It's like that Q&D oneliner I gave to scoupe to check for external activity on the I2C bus:
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ;
Just like assembler every word has a corresponding code that's assembled/compiled, just 19 bytes:
BEGIN - marks the address in memory to loop back to (no code) CR - assembles the implicit call to CR except in Tachyon it comprises a opcode for a vectored call and another byte to look up that vector. #64 - assembles the equivalent of a "mov tos,#64" essentially although it pushes the data stack down. FOR - pushes the count onto the loop stack and current address onto the loop branch stack (non-standard) P@ - a single opcode to read the contents of PORTA and push it onto the data stack #28 - immediate literal SHR - a single opcode to shift right SHR ( data bits -- data>>bits ) 3 - a single opcode for common literals AND - opcode to AND the top two data items together . - just print the top data item as a number in the current base NEXT - opcode to count and loop back quickly using the address that's sitting on top of the loop branch stack (DJNZ) ESC? - nice little routine that just checks to see if the last key (bypasses the buffer) was an escape and leaves a flag on the stack UNTIL - keep looping back using a byte offset to the BEGIN until the stack is true ; - EXIT or RET
A lot of these single operand opcodes execute in 400ns or a bit longer for stacking/unstacking.
(Here is the dump of the bytecodes I did through a Telnet session (extra echoes))
HERE . 5305 ok
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ;
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ; ok
HERE .
HERE . 5318 ok
' MON 20 DUMP
' MON 20 DUMP
0000_5305: C5 2A7E 40D98F7E 1C42873AC5 59E5C4 4D .*~@..~.B.:.Y..M
0000_5315: D0 120F 7D 53 05 7E 20 C4 89 0F 0F 00 00 00 00 ...}S.~ ........ ok
As for the FFT I'd forgotten all about it, what with the bother with my eye and delving into P1V and Verilog, it's too much fun (and pain). I will however get back to it and post some results although I feel that a "compiled" FFT would already be very good vs Forth where it is just "assembled"
I don't mind a little programming language benchmark or other challenged. But realistically if it's something that going to take more than the attention span of gnat to complete it's not going to get done by me. Not unless it is something like that FFT. I wanted to know how and why that crazy looking FFT algorithm worked, how to write my own from scratch. So a PASM and Spin version just had to be done just to see what could be done on the Prop.
I don't know about "the trouble" with Forth. Generally when I discuss these things I'm talking about the languages themselves. The syntax, the semantics, what you see on paper when you print it out. That is somewhat orthogonal to how they are implemented. Compiled, interpreted optimized or not, that's all a different topic. I don't know if there are any compilers for Forth but for sure I have seen interpreters for C. C may or may not have any optimization.
This gets confusing when debating languages with people and eventually you find out they are not talking about the language but something completely different like the features of the IDE they can use to write it. They don't seem to understand that a language and an IDE are different things.
You should not worry about the FFT Peter, I know pretty much all Propeller action around here as stopped dead whilst everyone is digging around with the P1 Verilog!
I wouldn't worry too much about what get's said, I am not impressed by those kinds of postings, it's almost trolling and plus there is nothing magical about any implementation, it's what gets done that's important (and also how much fun it is).
The trouble with Forth (but also a plus) is that it's not really a compiler, not in your C sense anyway as I know that a compiler doesn't just take a line of code and compile fixed known code, it also identifies and optimises structures too and a whole lot more. So Forth is said to compile code but since for every word of Forth you can be sure that it has compiled just that it is not much different to an assembler, albeit a high-level macroassembler, which is also why we can have specialized code optimized just right (or just plain wrong too).
I assume here you're talking about Tachyon Forth not Forth in general. Traditional Forths compile to threaded code not byte codes and I think Forth Inc. has an optimizing Forth compiler.
PASM programmers are likewise having it to easy and should use the much more tortuous Forth as well.
No, seriously.
One purpose of forth (at least PropFORTH) is to get one to the assembler part quicker. We can do the general stuff (90%) of the code in high level forth and only need to do the interesting bits in assembler. If you accept that it take ten time longer to write in assembler (at least for me this is true) and that programming in a high level language is quicker (at least for me this is also true) it means we can get the fast execution of assembler without t(most of the) very slow development in assembler.
But YOU should not use forth under any circumstance, since you don't like it. But his thread is about Prop architecture / family; not how much we or others likes or dislike a particualar tool.
But YOU should not use forth under any circumstance, since you don't like it. But his thread is about Prop architecture / family; not how much we or others likes or dislike a particualar tool.
Which also means it is not about Forth, C, Basic, Pascal, etc... Ad Nauseum. PASM is part of the chip architecture, so that is permissible ;-)
Actually...8 cores is shamefully short of where we should be now.
When I first started working with microprocessors professionally, in 1980, we only had single core machines. They were 8 bits and they had interrupts. Think 8085, Z80, 6809.
It was already clear to us that we did not actually want interrupts. What we wanted more "cores" (There was no such term at the time). So we built solutions with many of those 8 bit processors just so we could get the jobs done.
Now, we already had "Moore's law" predicting that the number of transistors we can put on a chip will probably double every two years.
Great, so we can have two cores instead of one in 1982. And four cores in 1984....this is going to be fantastic. We can shrink the size and cost of our solutions dramatically as time goes on.
So, by my reckoning Gordon Moore promised us, in 2014, after 34 years of process shrinks, the grand total of 131,072 cores to play with today!
OK. Where are they? What happened? What the hell has Chip been doing all this time?
Of course we did get our 100,000 times more transistors on a chip and we did get speeds up to 4GHz or whatever. But those Intel i7 and the like are pretty useless for deterministic real-time work.
On the bottom end, I've often wondered if a 4 core, 20 pin SOIC Propeller chip wouldn't be a useful device.
Software compatible with the p8x32, but much smaller and (of course) cheaper.
Given that industry has not embraced the Prop, there is little indication that a stripped down Prop would fare any better in the realm the $1 ARM and ASIC alternatives,
You know, it doesn't matter whether or not "industry" embraces Propellers. By percentage of share, we and the Prop do not matter.
But, it does matter if there are new prospects who will adopt the Propeller. A doubling of Parallax would not change "the industry' percentage of share number at all, but it would be huge for the Propeller, and it's ecosystem as it stands today.
What amazes me about Forth is the geometrical progression from primitives to ultra-high level coding in hardly any time at all. Every Forth program I've written has followed that same paradigm. The atom bomb paradigm.
In this respect ASM and Forth seem to differ, at least based on my own coding experience.
I agree. Forth is famous for being one of, or perhaps the, simplest way of bootstrapping from a bare machine into some kind of high level language and user interface. I think it' pretty clever in that respect. It has the minimal size and complexity for the maximal amount of usefulness.
For sure defining words out of words out of words gets you into a more and more high level description of your problem pretty quickly.
I'm not sure about the "ultra high level" anything. You are always stuck with the language you have which is pretty crude.
Also building more and more complex things out of lesser things is what you do in any high level language.
"The atom bomb paradigm." I like it. Not sure what it means but I like it. It could describe some of my most devastating programming efforts. Run the program and BOOM everyone dies. In a virtual sense usually:)
Also building more and more complex things out of lesser things is what you do in any high level language.
You can't, a C or whatever compiler is stuck at whatever level it's supplied to you. It is only a language that lives on a PC host long enough to generate those binary bits which become the cold cold target, then there is no "language" as such, just the impression of the stamp cast in silicon. So it's never been about which language is better, it's about the "development and runtime environment" and Forth is both the language and the environment and the heart that lives in the target system, beating away, able to grow into a more complex environment and each programmer is empowered to talk to it directly and extended even the language itself.
You can't, a C or whatever compiler is stuck at whatever level it's supplied to you. It is only a language that lives on a PC host long enough to generate those binary bits which become the cold cold target, then there is no "language" as such, just the impression of the stamp cast in silicon. So it's never been about which language is better, it's about the "development and runtime environment" and Forth is both the language and the environment and the heart that lives in the target system, beating away, able to grow into a more complex environment and each programmer is empowered to talk to it directly and extended even the language itself.
I agree that an interactive environment can be very productive. I also agree that Forth seems to be the best way to achieve this on a limited resource (especially memory) platform like the Propeller. However, can you make a case for using it on a less limited platform? It seems to me that you get the same interactivity in a more easily understood language if you go with something like Python or Javascript assuming your platform has the resources to run these languages. The only argument against that that I can see is that the languages may not be efficient enough for some realtime tasks. However, I would expect that productivity would be much higher with a more traditional language. Is there some advantage you see in Forth over other interactive language besides its ability to fit in tiny memory? Will there be a compelling reason to use it, for example, on P2 where hub memory is significantly larger?
Ultimately it doesn't matter what language(tool) you use as long as you're productive with it and have fun doing it. For some it's Forth, for others it's assembly, Pascal, etc.
I like Forth but I'm not a good enough coder to be good with it, it's a odd language to be sure. But it's certainly good enough though to end up in a half-dozen satellites and even be made into rad-hard processors(Harris RTX ims) that also ended up in orbiting the Earth. Variants of Forth live on as easy to implement FPGA forth engines like the Xylin/Zupino.
One of the main points of high level languages is to be able to compose more complex things out of simpler things.
In C there are atomic parts like variables and operators and means of composition like statements and functions. We build complex programs out of a recusive composition of those variables, operators, statements, functions.
In Forth there are numbers and words an everything is a composition of more words out of those parts.
I fail see how you can say "You can't" in response to my comment about composing programs with C.
So it's never been about which language is better,
So it seems. You are talking about having that nice command line interface from the get go on your target.
I have been talking about the language. The code as you have to read and understand, as you see when browsing the pages of github or printing it out on paper. The language that has to live in your brain to make that possible.
@rod1963,
Whilst the Zylin ZPU is a stack based processor architecture I refuse to believe that it "lives on" as any derivative of Forth. The stack based idea is in not unique to Forth. The ZPU for sure has features that make it un-Forth like.
Comments
When I first started working with microprocessors professionally, in 1980, we only had single core machines. They were 8 bits and they had interrupts. Think 8085, Z80, 6809.
It was already clear to us that we did not actually want interrupts. What we wanted more "cores" (There was no such term at the time). So we built solutions with many of those 8 bit processors just so we could get the jobs done.
Now, we already had "Moore's law" predicting that the number of transistors we can put on a chip will probably double every two years.
Great, so we can have two cores instead of one in 1982. And four cores in 1984....this is going to be fantastic. We can shrink the size and cost of our solutions dramatically as time goes on.
So, by my reckoning Gordon Moore promised us, in 2014, after 34 years of process shrinks, the grand total of 131,072 cores to play with today!
OK. Where are they? What happened? What the hell has Chip been doing all this time?
Of course we did get our 100,000 times more transistors on a chip and we did get speeds up to 4GHz or whatever. But those Intel i7 and the like are pretty useless for deterministic real-time work.
You know, this is really annoying.
There is no possible way, with my limited time and mental capacity and total disinterest in the idea and a billion other more interesting things I want to do instead, that I am ever going to study the FAT32 file system enough to be able to write a file system driver for it. Never mind the underlying SD card block driver. Sad but true.
So, I hereby concede defeat. I am totally convinced that Peter with Tachyon and no doubt others with their brands of Forth can do that in less space and faster than any C code I will ever write to do the same.
It is now obvious to me, by virtue of my resounding defeat in this simple challenge, that all those misguided users of Spin and C and whatever so called "high level languages" should desist in their folly and switch over to Forth.
PASM programmers are likewise having it to easy and should use the much more tortuous Forth as well.
....Mean while. Peter never did show us his version of the Fast Fourier Transform in Forth for the Propeller...I really like to see it because my effort at an FFT in Forth failed miserably. No, seriously.
Heater,
I am by no means new to the game. :nerd: In 1982 I was programming the 6502 in assembly on both the Apple and VIC-20 platforms. In 1985 I learned about the Z80 but didn't get into it until 1990 or so and used it until 2000 in commercial controllers. By 1988 I had also tasted 6800 and by 1990 the 68000 which I already had via my C= Amigas.
Hey, I finally have you beat at something! I was programming a Monrobot XI in junior high school in 1966 or thereabouts! :-)
However, that was nothing like programming micro controllers. One thing I really like about the work I've done on the Propeller and to a lesser extent on other MCUs is that I have to really think about how I'm going to fit a large application into the relatively small space and resources of an MCU. Programming desktop PCs doesn't give that satisfaction since you essentially have unlimited resources. I'm afraid MCUs are going in that direction too. I wonder what the next step will be where we have to make use of our skills at optimizing our use of resources? I kind of wonder what a P1 made with current processes would be like with 128 cores and some sort of 3D connection topology? Probably crazy but it would be fun like the current Propeller is fun. No matter what I say about the features of other chips, the Propeller is the only one I enjoy programming and keep coming back to.
But, perhaps partly because of that road block, there is now a big push downwards going on. Mobile computing, wareable computing, the Internet of Things, a processor in every light bulb or LED.
Down there they want low power, which means slow clocks, small processors and not much memory.
Oddly enough down there the arguments of the interrupt supporters win out over multiple cores. The power constraints dictate the minimum of transistors in the same way that they dictated the minimum number of vacuum tubes back in the day.
For sure there is a lot of opportunities for people who want to optimize things in the IoT world.
I think this probably says more about your C skills than it says about any supposed advantages Forth may have over C.
Ross.
Using that definition, I see many instances of the Propeller using interrupts: SPI CS pins, toggling an I2C SCL/SCK pin, the RESn and BOEn pins, et cetera.
I wouldn't worry too much about what get's said, I am not impressed by those kinds of postings, it's almost trolling and plus there is nothing magical about any implementation, it's what gets done that's important (and also how much fun it is).
The trouble with Forth (but also a plus) is that it's not really a compiler, not in your C sense anyway as I know that a compiler doesn't just take a line of code and compile fixed known code, it also identifies and optimises structures too and a whole lot more. So Forth is said to compile code but since for every word of Forth you can be sure that it has compiled just that it is not much different to an assembler, albeit a high-level macroassembler, which is also why we can have specialized code optimized just right (or just plain wrong too). It's like that Q&D oneliner I gave to scoupe to check for external activity on the I2C bus:
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ;
Just like assembler every word has a corresponding code that's assembled/compiled, just 19 bytes:
BEGIN - marks the address in memory to loop back to (no code)
CR - assembles the implicit call to CR except in Tachyon it comprises a opcode for a vectored call and another byte to look up that vector.
#64 - assembles the equivalent of a "mov tos,#64" essentially although it pushes the data stack down.
FOR - pushes the count onto the loop stack and current address onto the loop branch stack (non-standard)
P@ - a single opcode to read the contents of PORTA and push it onto the data stack
#28 - immediate literal
SHR - a single opcode to shift right SHR ( data bits -- data>>bits )
3 - a single opcode for common literals
AND - opcode to AND the top two data items together
. - just print the top data item as a number in the current base
NEXT - opcode to count and loop back quickly using the address that's sitting on top of the loop branch stack (DJNZ)
ESC? - nice little routine that just checks to see if the last key (bypasses the buffer) was an escape and leaves a flag on the stack
UNTIL - keep looping back using a byte offset to the BEGIN until the stack is true
; - EXIT or RET
A lot of these single operand opcodes execute in 400ns or a bit longer for stacking/unstacking.
(Here is the dump of the bytecodes I did through a Telnet session (extra echoes))
HERE . 5305 ok
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ;
pub MON BEGIN CR #64 FOR P@ #28 SHR 3 AND . NEXT ESC? UNTIL ; ok
HERE .
HERE . 5318 ok
' MON 20 DUMP
' MON 20 DUMP
0000_5305: C5 2A 7E 40 D9 8F 7E 1C 42 87 3A C5 59 E5 C4 4D .*~@..~.B.:.Y..M
0000_5315: D0 12 0F 7D 53 05 7E 20 C4 89 0F 0F 00 00 00 00 ...}S.~ ........ ok
As for the FFT I'd forgotten all about it, what with the bother with my eye and delving into P1V and Verilog, it's too much fun (and pain). I will however get back to it and post some results although I feel that a "compiled" FFT would already be very good vs Forth where it is just "assembled"
I don't mind a little programming language benchmark or other challenged. But realistically if it's something that going to take more than the attention span of gnat to complete it's not going to get done by me. Not unless it is something like that FFT. I wanted to know how and why that crazy looking FFT algorithm worked, how to write my own from scratch. So a PASM and Spin version just had to be done just to see what could be done on the Prop.
I don't know about "the trouble" with Forth. Generally when I discuss these things I'm talking about the languages themselves. The syntax, the semantics, what you see on paper when you print it out. That is somewhat orthogonal to how they are implemented. Compiled, interpreted optimized or not, that's all a different topic. I don't know if there are any compilers for Forth but for sure I have seen interpreters for C. C may or may not have any optimization.
This gets confusing when debating languages with people and eventually you find out they are not talking about the language but something completely different like the features of the IDE they can use to write it. They don't seem to understand that a language and an IDE are different things.
You should not worry about the FFT Peter, I know pretty much all Propeller action around here as stopped dead whilst everyone is digging around with the P1 Verilog!
One purpose of forth (at least PropFORTH) is to get one to the assembler part quicker. We can do the general stuff (90%) of the code in high level forth and only need to do the interesting bits in assembler. If you accept that it take ten time longer to write in assembler (at least for me this is true) and that programming in a high level language is quicker (at least for me this is also true) it means we can get the fast execution of assembler without t(most of the) very slow development in assembler.
But YOU should not use forth under any circumstance, since you don't like it. But his thread is about Prop architecture / family; not how much we or others likes or dislike a particualar tool.
Which also means it is not about Forth, C, Basic, Pascal, etc... Ad Nauseum. PASM is part of the chip architecture, so that is permissible ;-)
On the bottom end, I've often wondered if a 4 core, 20 pin SOIC Propeller chip wouldn't be a useful device.
Software compatible with the p8x32, but much smaller and (of course) cheaper.
But, it does matter if there are new prospects who will adopt the Propeller. A doubling of Parallax would not change "the industry' percentage of share number at all, but it would be huge for the Propeller, and it's ecosystem as it stands today.
It escapes me how bogging people down in a stack based machine is a good introduction to PASM which is anything but stack based. Yes I do accept that. Except Forth is not any kind of high level language and I fail to see how: is easier to understand than Yes indeed. PASM is on topic here. Forth is not.
What amazes me about Forth is the geometrical progression from primitives to ultra-high level coding in hardly any time at all. Every Forth program I've written has followed that same paradigm. The atom bomb paradigm.
In this respect ASM and Forth seem to differ, at least based on my own coding experience.
For sure defining words out of words out of words gets you into a more and more high level description of your problem pretty quickly.
I'm not sure about the "ultra high level" anything. You are always stuck with the language you have which is pretty crude.
Also building more and more complex things out of lesser things is what you do in any high level language.
"The atom bomb paradigm." I like it. Not sure what it means but I like it. It could describe some of my most devastating programming efforts. Run the program and BOOM everyone dies. In a virtual sense usually:)
You can't, a C or whatever compiler is stuck at whatever level it's supplied to you. It is only a language that lives on a PC host long enough to generate those binary bits which become the cold cold target, then there is no "language" as such, just the impression of the stamp cast in silicon. So it's never been about which language is better, it's about the "development and runtime environment" and Forth is both the language and the environment and the heart that lives in the target system, beating away, able to grow into a more complex environment and each programmer is empowered to talk to it directly and extended even the language itself.
I like Forth but I'm not a good enough coder to be good with it, it's a odd language to be sure. But it's certainly good enough though to end up in a half-dozen satellites and even be made into rad-hard processors(Harris RTX ims) that also ended up in orbiting the Earth. Variants of Forth live on as easy to implement FPGA forth engines like the Xylin/Zupino.
In C there are atomic parts like variables and operators and means of composition like statements and functions. We build complex programs out of a recusive composition of those variables, operators, statements, functions.
In Forth there are numbers and words an everything is a composition of more words out of those parts.
I fail see how you can say "You can't" in response to my comment about composing programs with C. So it seems. You are talking about having that nice command line interface from the get go on your target.
I have been talking about the language. The code as you have to read and understand, as you see when browsing the pages of github or printing it out on paper. The language that has to live in your brain to make that possible.
@rod1963,
Whilst the Zylin ZPU is a stack based processor architecture I refuse to believe that it "lives on" as any derivative of Forth. The stack based idea is in not unique to Forth. The ZPU for sure has features that make it un-Forth like.
Yeah if you want to nitpick, but for a while stack based processors and Forth were almost synonymous. Of course today it's not that way anymore.