SpainHackForth
2022-11-24 22:19:03 UTC
Hi all, may be my over incitement for Forth at the moment as I feel like there is so much value for it, and I have been pondering several aspects of the language, ideas on how to best leverage it and furthermore, extend the adoption of Forth and the Forth way.
Question; why has Forth not been as prolific as other languages?
Views:
Why is there a lack of cross compiler on Forth?
- IMHO, this is an area where Forth could do the community a great deal of good. If for example, there where crosscompilers for the embedded environments, this would potentially drive the adoption of the Language. Another thing that could be really interesting, Forth is a VM, why not extend CPU simulation on Forth, where one would test those targeted systems and make it "simple" to see how the app behaves at the hardware level and how to optimize it. I know metaprograming just looks natural in Forth, yet I see lots of Python, JS, and Java as having a large number of instruction set sims ( ISS ) out there on these platforms, I have not found a single one on Forth ( maybe I have not looked hard enough )
Further more, one are of inspiration is having something like https://cpulator.01xz.net/?sys=arm-de1soc&d_audio=48000
Well, that is a dream, but if you thing about it, the front end could run on a browser, the back end could be a forth system... If that is too much to ask, consider Gerog Heinrichs neat little MikroForth, well and if that is too much to ask then consider the following.. .
Program offset instruction Dis-assembled register/ storage (after execution)
TEST001 000000 X'05C0' BALR R12,0 R12=002CE00A
000002 X'47F0C00E' BC 15,X'00C'(R12)
00000E X'98ECD00C' STM R14,R12,X'00C'(R13) X'002E0008' ==> X'00004CE,002CE008,..etc....'
000012 X'45E0C122' BAL R14,X'122'(R12) R14=002C0016
SUB1 000124 X'50E0C28A' ST R14,X'28A'(R12) X'002CE294' ==> X'002C0016'
etc...
Ok, even a GDB interface to the ISS would be enough, really! :)
Furthermore, on the basis of use cases, I see lot's of discussion and people building FPGA based stack CPU's. I apologize in advance form my ignorance on the matter, but isn't Fort a VM for a CPU sort of speak? What can you really get out of substantially over priced, under power, higher barrier to entry, where you are designing the hardware, with it's pitfalls in the development phase, then the Forth that sits o top ( Ok so forth is the machine code, cool science project, one I would like to test ) but for a commercial application, I find to make the economic connection and or benefits.
If Forth is a VM kernel , would it not make sense to spend the time to have a vm that has a native Programmable Interrupt Controller with built in interrupt priority levels and streamline the code executed on these systems? I look at all the bloat that goes into projects like OpenWRT, and I just wonder if they where not better off moving to bare metal ( FORTH ) to deliver better performance? I also see that with the excess of compute available in the Arch64 space, there is plenty of opportunities to improve the performance and even consider, can you run a vm on top of a Forth kernel? That could be a way to further extend the portability of the system.
One area I see that this could be interesting is in high end embedded systems, where the CPU is really a peripheral of a larger systems, like dedicated cards that do networking or caching on larger servers... those systems build extensive and expensive systems, that have all the linux bloat on them, when in the end all they run is a 10K lines of code with a very specif purpose. I thought Forth could be the kernel. for these systems.
Furthermore, Forth brings another interesting option, if you are running a forth vm on top of a forth vm that runs the app or part of the app ( think of containers speaking to each-other at CPU speed.), then near real time upgrades could be possible or even bitecode up-gradable ( just updating the dictionary to point to a new portion of the code could be possible, that is a strong business case if you are targeting edge devices... smart meters, ect...
Just so much could be done.
Thoughts? Rebuttals? Ideas?
Question; why has Forth not been as prolific as other languages?
Views:
Why is there a lack of cross compiler on Forth?
- IMHO, this is an area where Forth could do the community a great deal of good. If for example, there where crosscompilers for the embedded environments, this would potentially drive the adoption of the Language. Another thing that could be really interesting, Forth is a VM, why not extend CPU simulation on Forth, where one would test those targeted systems and make it "simple" to see how the app behaves at the hardware level and how to optimize it. I know metaprograming just looks natural in Forth, yet I see lots of Python, JS, and Java as having a large number of instruction set sims ( ISS ) out there on these platforms, I have not found a single one on Forth ( maybe I have not looked hard enough )
Further more, one are of inspiration is having something like https://cpulator.01xz.net/?sys=arm-de1soc&d_audio=48000
Well, that is a dream, but if you thing about it, the front end could run on a browser, the back end could be a forth system... If that is too much to ask, consider Gerog Heinrichs neat little MikroForth, well and if that is too much to ask then consider the following.. .
Program offset instruction Dis-assembled register/ storage (after execution)
TEST001 000000 X'05C0' BALR R12,0 R12=002CE00A
000002 X'47F0C00E' BC 15,X'00C'(R12)
00000E X'98ECD00C' STM R14,R12,X'00C'(R13) X'002E0008' ==> X'00004CE,002CE008,..etc....'
000012 X'45E0C122' BAL R14,X'122'(R12) R14=002C0016
SUB1 000124 X'50E0C28A' ST R14,X'28A'(R12) X'002CE294' ==> X'002C0016'
etc...
Ok, even a GDB interface to the ISS would be enough, really! :)
Furthermore, on the basis of use cases, I see lot's of discussion and people building FPGA based stack CPU's. I apologize in advance form my ignorance on the matter, but isn't Fort a VM for a CPU sort of speak? What can you really get out of substantially over priced, under power, higher barrier to entry, where you are designing the hardware, with it's pitfalls in the development phase, then the Forth that sits o top ( Ok so forth is the machine code, cool science project, one I would like to test ) but for a commercial application, I find to make the economic connection and or benefits.
If Forth is a VM kernel , would it not make sense to spend the time to have a vm that has a native Programmable Interrupt Controller with built in interrupt priority levels and streamline the code executed on these systems? I look at all the bloat that goes into projects like OpenWRT, and I just wonder if they where not better off moving to bare metal ( FORTH ) to deliver better performance? I also see that with the excess of compute available in the Arch64 space, there is plenty of opportunities to improve the performance and even consider, can you run a vm on top of a Forth kernel? That could be a way to further extend the portability of the system.
One area I see that this could be interesting is in high end embedded systems, where the CPU is really a peripheral of a larger systems, like dedicated cards that do networking or caching on larger servers... those systems build extensive and expensive systems, that have all the linux bloat on them, when in the end all they run is a 10K lines of code with a very specif purpose. I thought Forth could be the kernel. for these systems.
Furthermore, Forth brings another interesting option, if you are running a forth vm on top of a forth vm that runs the app or part of the app ( think of containers speaking to each-other at CPU speed.), then near real time upgrades could be possible or even bitecode up-gradable ( just updating the dictionary to point to a new portion of the code could be possible, that is a strong business case if you are targeting edge devices... smart meters, ect...
Just so much could be done.
Thoughts? Rebuttals? Ideas?