Author Topic: I miss 'FORTH' the programming language (Read 8628 times)

GlennSprigg · « **on:** September 03, 2018, 02:26:22 pm »

Countless fads in life come & go. This should have stayed, as it is/was so different !!
It relies heavily on 'Stacks', and 'R.P.N.' for calculations, but was so easy to implement.
'Command' words were based on certain 'Primitives', from which you built higher and
higher level 'Words' from. To the end that you virtually create such a 'High' level 'Word'
or instruction, with certain parameters, that their is no 'program' as such.
It was used inside a lot of Chips in specialized instruments for quite a while.
I won't explain more here, but will if asked !!

It REALLY shouldn't have died....

NivagSwerdna · « **Reply #1 on:** September 03, 2018, 02:39:41 pm »

I have GForth on my Android phone. Looks alive to me.

ebclr · « **Reply #2 on:** September 03, 2018, 02:41:56 pm »

artag · « **Reply #3 on:** September 03, 2018, 06:47:22 pm »

Postscript is based on it. I don't think that's died.

kizmit99 · « **Reply #4 on:** September 03, 2018, 08:08:42 pm »

ebclr - thanks for posting the link to the video

I used Forth for a summer back in the early eighties as a co-op student with IBM. It's certainly "different" as languages go, but it's also enchantingly elegant...

borjam · « **Reply #5 on:** September 03, 2018, 08:46:52 pm »

I used it for embedded systems in the early 90's

I was a member of the Forth Interest Group even.

By the way, Mitch Bradley (the original Open Firmware author) has a Github repository with his CForth implementation.

https://github.com/MitchBradley/cforth

daybyter · « **Reply #6 on:** September 04, 2018, 01:47:18 am »

Just did some work on a zylin cpu implementation. Pretty similar and also very alive.

darrellg · « **Reply #7 on:** September 04, 2018, 05:43:54 pm »

https://learn.adafruit.com/alternative-languages-for-programming-SAMD-boards/forth

RoGeorge · « **Reply #8 on:** September 04, 2018, 06:06:12 pm »

Forth is well and alive all over the place.

Nowadays, in the golden era of microcontrollers, embedded and Iot, it is spreading more than ever, especially because Forth has a very small footprint, and it's very easy to deploy to various architectures (a one man job, literally).

You can even practice it online if you like, no need to install or buy something (don't know if this is a good online IDE, just the first search result for 'Forth online'):
https://repl.it/repls/ShowyTerribleAdmin

David Hess · « **Reply #9 on:** September 05, 2018, 02:45:52 am »

The Open Firmware standard from Sun used FORTH to allow PCI expansion cards to operate on systems with different processors. I guess that idea was too effective and too easy because it was replaced with Intel's EFI.

borjam · « **Reply #10 on:** September 05, 2018, 07:24:59 am »

Quote from: David Hess on September 05, 2018, 02:45:52 am

The Open Firmware standard from Sun used FORTH to allow PCI expansion cards to operate on systems with different processors. I guess that idea was too effective and too easy because it was replaced with Intel's EFI.

Open Firmware was processor independent. You ported Forth and even the device driver firmware you would need to access from Open Firmware (boot support for disk controllers, etc) would be portable. I guess Intel liked the idea of a CPU independent device support just like Microsoft loved the notion of virtual machines and the Sun/Oracle "Network Computer"

David Hess · « **Reply #11 on:** September 05, 2018, 12:34:18 pm »

Quote from: borjam on September 05, 2018, 07:24:59 am

I guess Intel liked the idea of a CPU independent device support just like Microsoft loved the notion of virtual machines and the Sun/Oracle "Network Computer"

Maybe Intel saw the potential for ARM to be a threat to their desktop market so killed processor independent firmware with EFI. In any event, it is another great idea that is now dead.

GlennSprigg · « **Reply #12 on:** September 05, 2018, 01:51:05 pm »

Wow!... I'm glad it's interest is still current !!
When I said 'dead', I meant no longer prevalent as it was in the 80's, 90's.

The video link/post by ebclr amazed me !!! The Video was honestly above my level, but I followed
enough to grasp the contemporary usefulness of the described Mecrisp Forth, on STM32 Microcontroller.

I loved the way 'Forth', not 'Fourth', (as the original system at conception could only handle 5-char filenames!)
was so immediately useable while defining 'words' without re-compiling etc. You could make it almost so
English like, in structuring commands/sentences, (seemingly) without a 'program' as such, but simply constantly
defining higher & higher level Words. (With parameters). Control of actual Inputs/Outputs was beautiful !!

I guess i was talking here, more to those that are un-familiar :-)
It was a strange beast :-) The first implementation that 'I' saw/had, was on a plug-in Cartridge on the
Commodore-64. This was before I found out about it's implementation in numerous chips/devices.
(35 - 40 years ago !!! :-) )

iMo · « **Reply #13 on:** September 05, 2018, 07:22:09 pm »

Mecrisp Forth running on a J1a_enhanced CPU (UPduino iCE40UP5k FPGA)
https://github.com/igor-m/UPduino-Mecrisp-Ice-15kB

borjam · « **Reply #14 on:** September 06, 2018, 11:26:38 am »

Quote from: David Hess on September 05, 2018, 12:34:18 pm

Quote from: borjam on September 05, 2018, 07:24:59 am

I guess Intel liked the idea of a CPU independent device support just like Microsoft loved the notion of virtual machines and the Sun/Oracle "Network Computer"

Maybe Intel saw the potential for ARM to be a threat to their desktop market so killed processor independent firmware with EFI. In any event, it is another great idea that is now dead.

Yes, hence my sarcasm

Another great idea killed by the Wintel duopoly. And every time I have to deal with one of those hideous "BIOS" configuration tools, clearing the screen like naive Basic programmers and forcing you to shoot videos in order to catch rare errors I get violent.

FreeBSD has a Forth loader actually but without actual device drivers built in it's not so useful.

https://www.freebsd.org/cgi/man.cgi?loader(

Back in the early 90's you should have seen the face of a friend when I booted a Sun workstation, aborted the startup to get into OpenBoot (that's how they called OpenFirmware) and I typed several silly Forth words. He couldn't believe it!

LapTop006 · « **Reply #15 on:** September 07, 2018, 05:45:55 am »

Quote from: David Hess on September 05, 2018, 12:34:18 pm

Quote from: borjam on September 05, 2018, 07:24:59 am

I guess Intel liked the idea of a CPU independent device support just like Microsoft loved the notion of virtual machines and the Sun/Oracle "Network Computer"

Maybe Intel saw the potential for ARM to be a threat to their desktop market so killed processor independent firmware with EFI. In any event, it is another great idea that is now dead.

EFI *is* processor independent. It mostly started off as the firmware layer for Intel Itanium machines, then Apple used it when they moved from (Open Firmware) PowerPC to x86, and now more recently UEFI has replaced the old BIOS for most x86-64 PCs, and it's even used by ARM64 servers.

It certainly does have it's weirdnesses, but so do all the firmware options.

borjam · « **Reply #16 on:** September 07, 2018, 07:19:04 am »

Quote from: LapTop006 on September 07, 2018, 05:45:55 am

EFI *is* processor independent. It mostly started off as the firmware layer for Intel Itanium machines, then Apple used it when they moved from (Open Firmware) PowerPC to x86, and now more recently UEFI has replaced the old BIOS for most x86-64 PCs, and it's even used by ARM64 servers.

Open Firmware uses Forth, a high level language.

As long as you provide the right primitives in machine code, the rest of the code is processor indepent.

So, imagine that you have a PCI network card with some initialization code in firmware. If the firmware is Open Firmware, the same card with the same firmware in flash or ROM will work on a machine regardless of the processor. You don't need to choose SPARC firmware or PowerPC for example.

Is that possible in EFI? Having several compiled versions for different processors doesn't count. With Open Firmware you would support even future processors without touching the ROM or flash memory in the add-on card.

For someone not familiar with this notion, it would be similar to having firmware written in Python.

guenthert · « **Reply #17 on:** September 12, 2018, 07:28:28 am »

OLPC-1 used Open Firmware too, which was a bit controversial due to the proprietary nature of the software and it being a one-man project (like virtually all FORTH projects). Somehow FORTH seems to attract people interested in quick initial results, rather than long term cooperation. Yeah, perhaps one could summarize FORTH as the quickest way to get to the 80% solution

Said that, FORTH does seem to be a good fit for the retro and steam-punk computers (usually single-person projects as well) and it sure is fun. Over at forums.parallax.com Peter Jakacki quite actively maintains Tachyon, a fast FORTH implementation for the Propeller MCU.

borjam · « **Reply #18 on:** September 12, 2018, 10:18:16 am »

Quote from: guenthert on September 12, 2018, 07:28:28 am

OLPC-1 used Open Firmware too, which was a bit controversial due to the proprietary nature of the software

So people is using Linux on proprietary hardware with extremely proprietary processors and so on.

I remember when Intel was called "open" while SPARC (despite being an open standard) was considered "proprietary". Ah, doublethink!

Quote

and it being a one-man project (like virtually all FORTH projects). Somehow FORTH seems to attract people interested in quick initial results, rather than long term cooperation. Yeah, perhaps one could summarize FORTH as the quickest way to get to the 80% solution

Said that, FORTH does seem to be a good fit for the retro and steam-punk computers (usually single-person projects as well) and it sure is fun. Over at forums.parallax.com Peter Jakacki quite actively maintains Tachyon, a fast FORTH implementation for the Propeller MCU.

Being one man or team work depends on your working style. I've used Forth in the real world 20 years ago and it was certainly a quick and efficient way to build an embedded application for an 8 bit microcontroller. Nowadays, when programming begins with mastering a complex mix of poorly docuemnted multi-gigabyte class libraries, it doesn't fit of course. But that's an entirely different story.

Compared to the two typical alternatives at the time, C and raw assembler, it was really awesome.

TheNewLab · « **Reply #19 on:** December 13, 2018, 04:31:18 am »

US government still need FORTH programmers...go figure...

EEVblog · « **Reply #20 on:** December 13, 2018, 05:12:31 am »

The data recorder that's in my logo photo runs Forth on a TMS320, compiler only available in German!

iMo · « **Reply #21 on:** December 13, 2018, 09:09:26 am »

Quote

Compared to the two typical alternatives at the time, C and raw assembler, it was really awesome.

None C at that time existed, imho..

rrinker · « **Reply #22 on:** December 14, 2018, 06:34:54 pm »

Quote from: TheNewLab on December 13, 2018, 04:31:18 am

US government still need FORTH programmers...go figure...

I just got finished with a project that was evaluating application being used by the client for compatibility with upgraded server infrastructure. At least one of them is STILL promarily customized by programming in COBOL.

FORTH has intrigued me at various times but I never really set out to learn it - perhaps I should.

rhb · « **Reply #23 on:** December 14, 2018, 10:55:39 pm »

The Kitt Peak radio telescope was programmed in forth. And the airport baggage handling system at the Riyahd airport. Forth, Inc. is still in business, so I'd say it's a safe bet forth is used a lot more than people think.

If you have to program a one off piece of real time hardware it's pretty hard to beat. It is the bare minimum you need to have a portable piece of software that accommodates incremental changes to the hardware gracefully.

This is in my view the best book for understanding the forth model:

https://www.amazon.com/Threaded-Interpretive-Languages-Design-Implementation/dp/007038360X

When I looked it up a week or so ago a copy was $10.

tsman · « **Reply #24 on:** December 14, 2018, 11:09:36 pm »

Quote from: borjam on September 07, 2018, 07:19:04 am

So, imagine that you have a PCI network card with some initialization code in firmware. If the firmware is Open Firmware, the same card with the same firmware in flash or ROM will work on a machine regardless of the processor. You don't need to choose SPARC firmware or PowerPC for example.

Is that possible in EFI? Having several compiled versions for different processors doesn't count.

Yes. You can have both types in UEFI. EFI Byte Code drivers which are processor independent but need a EBC interpreter and regular executables which are tied to that architecture or platform but may be executed directly by your OS. It is up to whoever implements it.

stevelup · « **Reply #25 on:** December 17, 2018, 09:56:45 pm »

Quote from: rrinker on December 14, 2018, 06:34:54 pm

At least one of them is STILL promarily customized by programming in COBOL.

COBOL is still very much here...

One of our primary business apps runs on this.

rrinker · « **Reply #26 on:** December 23, 2018, 04:52:43 am »

MicroFocus COBOL is indeed what is embedded in the HR app I was referring to.

Now that's an old name - or sort of at least, I certainly remember seeing ads for MicroFocus compilers back at least to the early 80's - prior to then I rarely read computer-focused magazines, I was a PE subscriber. Read the occasional Byte at the library after I picked out my books and was waiting for my Mom and sister to finish.

rhb · « **Reply #27 on:** December 23, 2018, 01:02:03 pm »

Focus was a major mainframe database package. MicroFocus appeared when the IBM PC was introduced. I never used Focus directly, but lots of reports I generated while processing seismic data were produced by Focus applications.

techman-001 · « **Reply #28 on:** December 26, 2018, 12:57:02 pm »

The rumors of the death of Forth have been greatly exaggerated ;-)

I have been maintaining a Forth documentation site for Mecrisip-Stellaris http://hightechdoc.net/mecrisp-stellaris/_build/html/index.html since around 2014 and it gets about 80 - 100 unique hits a day.

Mecisp-Stellaris caters for ARM Cortex-M while Mecrisp caters for MSP-430.

There is also a Mecrisp-Quintus for RISC-V and PIC32, a Mecrisp-ICE which is an enhanced version of Swapforth and the J1a stack processor by James Bowman.

Mecrisp-Across is a tethered Forth for the MSP430, which uses a Ti Tiva Connected Launchpad as the cross-compiler and a 4 wire JTAG umbilical. The target MSP430 MCU does not use any preloaded firmware, and will run with only 500 Bytes of Flash, appearing to have a full Forth on board with 64KB of Flash. http://hightechdoc.net/mecrisp-across/_build/html/index.html

I have also started doing a few YouTube videos to demonstrate that Forth is keeping up with the times and also because there just aren't a lot of Forth videos around. https://www.youtube.com/watch?v=kDi-Nlz3-QA. They are pretty basic videos and not up to the high standard of eevblog, so don't expect too much!

I mainly use the STM32F051 for all my projects and examples as it's cheap, fast, tiny and immensely capable.

The Mecrisp* Home Page is: http://mecrisp.sourceforge.net/

Cheers,
Terry


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: I miss 'FORTH' the programming language (Read 8628 times)

Share me