Linked by Conrad Voorsanger on Thu 2nd Jun 2011 16:28 UTC
Original OSNews Interviews OSNews sat down with Ian Seyler, the Founder and Lead Programmer at Return Infinity, the maker and sponsor of Baremetal OS, a 64-bit OS for x86-64 based computers written entirely in Assembly. Editor's note: We'd love to do similar interviews with the people behind other alternative or hobby OS projects. If there's a project that you'd like to learn more about, let us know.
Thread beginning with comment 475991
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Why not in Forth?
by Zbigniew on Sat 4th Jun 2011 11:52 UTC in reply to "RE: Why not in Forth?"
Zbigniew
Member since:
2008-08-28

> What does forth offer as a compelling reason to learn/use it?

You didn't read anything like "Starting Forth"? OK, here you go:

Forth is fast. High-level Forth executes as fast as other high-level languages and between 20 to 75% slower than equivalent assembly-language programs, while time-critical code may be written in assembler to run at full processor speed. Without a traditional operating system, Forth eliminates redundancy and needless run-time error checking.

Forth compiled code is compact. Forth applications require less memory than their equivalent assembly-language programs and consume less power (important for hand-helds and portable gadgets!) Written in Forth, the entire operating system and its standard word set reside in less than 8K bytes. Support for a target application may require less than 1K bytes.

Forth is transportable. It has been implemented on just about every mini- and microcomputer known to the industry. Most microcontrollers and DSPs, even tiny ones, also have a Forth implementation.

Forth has been known to cut program development time by a factor of ten for equivalent assembly-language programming and by a factor of two for equivalent high-level programming in C or Java. Productivity increases because Forth epitomizes "structured programming" and because it is interactive and modular.

Reply Parent Score: 1

RE[3]: Why not in Forth?
by Alfman on Sat 4th Jun 2011 20:53 in reply to "RE[2]: Why not in Forth?"
Alfman Member since:
2011-01-28

Zbigniew,

"You didn't read anything like "Starting Forth"? OK, here you go:"

No, I never had reason to before. I am looking at it now. It'd take me a while to get used to, but I can see how the stack based approach translates very easily to CPU stack.

"Forth compiled code is compact. Forth applications require less memory than their equivalent assembly-language programs and consume less power (important for hand-helds and portable gadgets!)"

Something doesn't seem right about this. Either forth is emulating a more compact byte code than x86, or it's executing native x86 code. I don't understand how it can be both smaller and as efficient as assembly, can you elaborate?


"Forth is transportable. It has been implemented on just about every mini- and microcomputer known to the industry. Most microcontrollers and DSPs, even tiny ones, also have a Forth implementation."

Portability is huge, however in my experience platform specific APIs hinder portability more so than the language itself. Does forth have a standard API for things like networking, name resolution, databases, threading, graphics, etc?

From my initial reading, the forth language doesn't specify these things but I could be wrong.

"Forth has been known to cut program development time...for equivalent high-level programming in C or Java."

I'm sure this is true for many cases. But what about compared against ruby, or python, C#, or even something like haskell?

The question is difficult to answer (at least for me) because I don't have the time to implement the same program in a dozen different languages to compare the relative difficulty.

Haskell/Prolog have a very unique capability to run many functions backwards (given the output, it will enumerate all possible inputs).

Forth's reverse polish notation stands out, but it's not immediately obvious to me that it's a better way of thinking about code. If I had more experience with it, maybe I'd change my mind.

In terms of simplicity, there is no contest, the trivial nature of RPN blows everything else out of the water.

In terms of technical superiority, I don't know so much. Java also uses a similar stack driven implementation under the hood.

I might like it once I got used to it. But, realistically it's difficult to justify spending time to become fluent in forth when employers aren't asking for it.


Edit: I wanted to say that I do agree with you that it looks like it would be a natural fit in an operating system context. It does does seem more suitable than the other languages I brought up. Particularly for algorithms.

Edited 2011-06-04 21:01 UTC

Reply Parent Score: 2

RE[4]: Why not in Forth?
by Zbigniew on Sat 4th Jun 2011 21:13 in reply to "RE[3]: Why not in Forth?"
Zbigniew Member since:
2008-08-28

"Forth compiled code is compact. Forth applications require less memory than their equivalent assembly-language programs and consume less power (important for hand-helds and portable gadgets!)"

Something doesn't seem right about this. Either forth is emulating a more compact byte code than x86, or it's executing native x86 code. I don't understand how it can be both smaller and as efficient as assembly, can you elaborate?

But while reading "Starting Forth" you surely noticed, where I copy the above from? ;)
I understand that statement, that using Forth words, instead of coding in assembly, usually overall size of your code is smaller, when programming in Forth. I think, it depends on quality of macroassembler you can use, quality of Forth compiler, which you're comparing to - and, of course, on your skills both as assembler- and Forth-coder.

Portability is huge, however in my experience platform specific APIs hinder portability more so than the language itself. Does forth have a standard API for things like networking, name resolution, databases, threading, graphics, etc?

No. Actually, programming in Forth is rather "designing one's own problem-specific language". Forth is the basis. Then instead of using ready-available high-level function (which you'll find in langs like Python), you're designing your own higher-level language using Forth words.

I'm sure this is true for many cases. But what about compared against ruby, or python, C#, or even something like haskell?

The question is difficult to answer (at least for me) because I don't have the time to implement the same program in a dozen different languages to compare the relative difficulty.

Of course, it's not that easy to measure it. Since I'm Forth-newbie (learning it about year for now), you may be interested in asking these questions on comp.lang.forth, where you'll meet several experienced Forth-programmers, coding in Forth more than 20 years.

Reply Parent Score: 1