6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat May 11, 2024 11:18 pm

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Tue Jun 09, 2020 6:55 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10800
Location: England
There's a blog post here
Collapse OS — Why Forth?

which links to a long conversation on a ticket here

which tells the story of one person's journey from hearing about Forth to trying it to adopting it for their major project, being Collapse OS, a ground-up operating system. (Previously being written in assembler.)

(I would highly recommend we stick to the Forth aspects of this, not the futurology behind the project, as that is very off-topic. As for the Z80 aspect, I think that's incidental.)

Quote:
Collapse OS' first incarnation was written in Z80 assembler. One of the first feedbacks I had after it went viral was "why not Forth?". I briefly looked at it and it didn't seem such a great choice at first, so I first dismissed it.


The main advantages given in the blog post for adopting Forth are
    compactness
    a culture of simplicity
    portability
Quote:
Because compactness has always been a primary design goal of Collapse OS, I initially chose Z80 assembler over high level languages so that I could continue to meet that design goal.

However, now that I can have my cake and eat it too, thanks to Forth, new opportunities open. First and foremost, multiple architectures! Although I was ready to give that up when I tied myself to the Z80, I'm now very glad to have it and will certainly take advantage of it.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 09, 2020 5:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8180
Location: Midwestern USA
I took the time to read the linked pages, mainly because of my long-standing interest in operating system design. This is not a critique, just some out-loud thinking.

BigEd wrote:
The main advantages given in the blog post for adopting Forth are

    compactness

Yes, Forth can appear to be very compact—if one chooses to ignore all the stuff behind the curtain that makes Forth work. I suspect one will find Forth's overall footprint is larger than an equivalent that was efficiently written entirely in assembly language. With any interpreted language, the overhead stays relatively constant, even with the smallest programs. With assembly language, the only overhead is that which the programmer chooses to include in the source code.

Quote:
    a culture of simplicity

That's all a matter of opinion. :D Forth enthusiasts see Forth as simple. Much of the computing universe sees Forth as an arcane melánge of disjointed words, symbols and reverse Polish gibberish. I'm part of the latter group, and view assembly language as much less impenetrable and more logical than Forth.

On the other hand, if one considers the rapidity at which a Forth program can be written by someone fluent in the language, I suppose there is simplicity over the process of edit/assemble/link/execute. However, that is the case for most interpreted languages.

Quote:
    portability

No operating system is truly portable, especially in the 8-bit microcomputer world. There are always system dependencies that have to be resolved and almost always, they have to be resolved with system-specific assembly language. As Forth cannot execute in a vacuum and must ultimately interact with the underlying hardware, the Forth kernel has to be written for the particular machine architecture on which it is expected to run, which makes it non-portable.

My takeaway is the author of Collapse OS is probably not an expert Z80 assembly language programmer, which would explain why he decided to rewrite it in Forth—there's no question writing an OS in pure assembly language is a daunting task. Also, he notes in his writeup he is a Python developer, which suggests he is likely more comfortable with languages that insulate the programmer from the bare metal (which is a paradox of sorts, considering that at some point an operating system has to be in contact with device registers, etc.). However, he clearly understands the performance implications of writing an OS in Forth, as well as possible maintenance issues related to the language's syntax and structure (this latter item is likely a reason why Forth has not enjoyed much popularity in the general programming community).

BTW, the individual who wrote Collapse OS is a "prepper," which explains the software's name.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 09, 2020 6:02 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10800
Location: England
> I would highly recommend we stick to the Forth aspects of this


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 09, 2020 7:26 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8433
Location: Southern California
BigDumbDinosaur wrote:
I took the time to read the linked pages, mainly because of my long-standing interest in operating system design. This is not a critique, just some out-loud thinking.

BigEd wrote:
The main advantages given in the blog post for adopting Forth are

    compactness

Yes, Forth can appear to be very compact—if one chooses to ignore all the stuff behind the curtain that makes Forth work. I suspect one will find Forth's overall footprint is larger than an equivalent that was efficiently written entirely in assembly language. With any interpreted language, the overhead stays relatively constant, even with the smallest programs. With assembly language, the only overhead is that which the programmer chooses to include in the source code.

It's basically like this:
Attachment:
efficiency1.gif
efficiency1.gif [ 12.95 KiB | Viewed 1209 times ]

where the Forth kernel takes memory before you even start you application. It could be as little as a couple of KB, but that's not practical or realistic for most applications. 8KB is probably more of a realistic minimum. As you add more and more of the regular Forth functions to it, they can more than pay for themselves in a larger application, but obviously not in a small one. That is of course true of non-kernel routines too, which is why both curves are curved. For small jobs though, ie, the left end of the graph, assembly language definitely wins on memory efficiency.

For the things I've used PIC16 microcontrollers for in my work starting in the mid-1990's, Forth is out of the question, not just because of the PIC16's mickeymousities, but also because the amount of available program memory limits you to the extreme left portion of my sketched graph. That was ok for the kind of stuff I had the PICs do. I do however use Forth-like program flow-control structures in the macros to make it a lot more clear what's going on. As for RPN, you just have to think like the Korean language: it's "shoes, install," rather than "put on your shoes."

Quote:
Quote:
    a culture of simplicity

That's all a matter of opinion. :D Forth enthusiasts see Forth as simple. Much of the computing universe sees Forth as an arcane melánge of disjointed words, symbols and reverse Polish gibberish. I'm part of the latter group, and view assembly language as much less impenetrable and more logical than Forth.

It's simple in the sense that there are virtually no syntax requirements or punctuation, and it's well within the ability of any intermediate Forth programmer to understand even the compiler's innards, and extend it or modify it. As for the symbols (which may appear to be punctuation), they're just words with extremely short names, done that way because they're the ones used all the time and there's no chance of forgetting them, like store, fetch, and starting or ending a definition, and they take very little room on a line.

Quote:
BTW, the individual who wrote Collapse OS is a "prepper," which explains the software's name.

Some of us are kind of stubborn about not being dependent on a supplier for support or updates, which is why Forth will never die. It doesn't need these. That's also why it's hard to make money selling Forth. I think most of Forth, Inc.'s income for example comes from selling their programming services for large industrial, healthcare, aerospace, and scientific applications, not from selling their SwiftForth or SwiftX, kind of like WDC making most of their money licensing IP, not selling parts.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 10, 2020 12:22 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8180
Location: Midwestern USA
BigEd wrote:
> I would highly recommend we stick to the Forth aspects of this

I did.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 10, 2020 7:34 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10800
Location: England
Sorry, I made a mistake, I expressed my intent too tersely for it to be useful. My aim was to forestall any discussion of the person behind this adventure, or their reasons for undertaking it, because that's solidly off-topic and isn't what interesting (to me, here on this forum) about the story.

For me, the interesting and on-topic aspects of the story are
- what might initially not appeal to a person when first encountering Forth
- what about Forth might eventually win them over
- how they might express themselves having become a convert to Forth

Other potentially interesting and on-topic aspects might be
- how to use this story to bring people on board
- how the conversion of this particular OS from assembly to Forth might go
- how Forth can be taught or learnt

The rather long conversation in the Github issue shows how a person's opinion can change over the course of some space of time, when the conversation remains supportive and addresses a person's present state of mind at each point.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 10, 2020 8:12 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8433
Location: Southern California
It's interesting to see the discussion there from a bunch of people most of whom are ignorant about it and just a few that try to inform them. I tried to sign in for the discussion but had my usual difficulties with github and have not been able.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 14, 2020 8:19 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8433
Location: Southern California
I came across this bit from Wikipedia, about the Starflight videogame:

    The team coded the game mostly in Forth[14] with a few key routines written in x86 assembler [sic]. Forth was chosen since it is easier to use than assembler and more compact. This was important because the game had to fit into 128K of RAM.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: