It's hard to see practical strengths, especially with provided code examples. Most of tax code is stack tossing hiding core logic.<p>Code as structure could be more conveniently expressed as language data structures as structure nowdays.
Considerably better than most such articles that I have read on this but I think if the Forth community wants to get people into Forth it really needs to stop talking about how it can fit in a boot sector and the REPL; the former is not of interest or use to most programmers and the latter is probably a major cause of the misconception of Forth code being impossible to read.<p>What I see as the real strength of Forth is that if you write your program in source files, there is no abstraction. You stick your word definitions in those source files and let the application you are writing dictate the words you define instead of relying on the dictionary you built up on REPL and things quickly start becoming easy and the code remains readable. It might seem like a lot of work and endlessly reinventing the wheel but if you start with a featureful Forth like gforth it does not take that much time or effort once you have the basics down; you can build complex applications with gforth as easily as you can build up a full Forth with that minimal Forth that fits in your boot sector.<p>The main thing is learning that application development with Forth is top down design and bottom up writing. You break the application up into its major functions, break those into smaller functions, break those into words and then break those words into those simple sort words that everyone in the Forth community says you should write. Then you start writing code. I am just starting to get the hang of Forth and it is surprisingly quick and powerful once you start getting the sense of it.
Oh, cool! SmithForth[0] is how I originally learned about x86-64 microarchitecture. It's a Forth that bootstraps off hand-coded x86-64 opcodes. I decided to go the other direction and decompile the binary by hand. It really is a beautiful piece of code. Highly recommended reading.<p>Also, you're excited by Forth and Lisp, you might like Forsp[1]. It uses a call-by-push-value evaluation strategy in a way that really makes the language feel like a true hybrid of the two. The implementation is also brilliantly simple.<p>Anyway, thank you for the article. I lurk on the DuskOS mailing list and wish I could find out where the Forthers gather IRL so I could osmote more of their world into my own.<p>[0]:<a href="https://dacvs.neocities.org/SF/" rel="nofollow">https://dacvs.neocities.org/SF/</a><p>[1]:<a href="https://xorvoid.com/forsp.html" rel="nofollow">https://xorvoid.com/forsp.html</a>
There is an aspect of the history of Forth and C I have been trying to wrap my head around.<p>The early B compiler was reported to generate threaded code (like Forth). The threaded code was abandoned fairly early in the port to the PDP11 from the PDP7 as it was deemed to slow to write an operating system in.<p>At which point unix and C lost a very interesting size optimization. With the net result that Forth was more portable and portable between machines circa 1970 and Unix had to wait until circa 1975 with UnixV6.<p>I have been trying to go back through the history to see if I could understand why threaded code was deemed too slow. Today the most part of executables is code that is not run often and would probably benefit from a smaller representation (less memory and cache space making the system faster overall). So this is a practical question even today.<p>I found a copy of unix for the PDP7. Reproduced from old printouts typed in. If I have read the assembly correctly the B compiler was not using an efficient form of threaded code at all.<p>The PDP7 is an interesting machine. It's cells were 18 bits wide. The adress bus was 12bits wide. Which meant there was room for an opcode and a full address in every cell.<p>As I read the B compiler it was using a form of token threading with everything packed into a single 18 bit cell. The basic operations of B were tokens and an if token encoded with a full address in the cell. Every token had to be decoded via a jump table, the address of the target code was then plugged into a jump instruction which was immediately run.<p>Given the width of the cells, I wonder what the conclusions about performance of B would have been if subroutine threading or a similar technique using jmp instructions would have been.<p>Does anyone know if Forth suffers measurably in inner loops from have to call words that perform basic operations?<p>Is this where a Forth programmer would be accustomed to write the inner loop in assembly to avoid the performance penalty?
It is no so much the parts of the code that run infrequently that contribute to poor performance, but the very tiny <1% of all code that does run frequently, and should be running completely in cache. So code size doesn't have an enormous impact on speed of execution.<p>The overhead of threading seems pretty obvious: call and return instructions are expensive compared to the cost of the one equivalent instruction that would have been executed in a compiled implementation. And placing arguments on a stack means that all operands have to to be read from and written to memory, incurring additional ferocious overhead, whereas a compiler would enregister values, particularly in performance-critical code. Not unreasonable to expect that Forth code is going to run at least an order of magnitude slower than compiled code.
I can probably shed some light on that. I've used Forth on 8 bit platforms (6502, 6809), 16 bit platforms (80286) and 32 bit platforms (68K), as well as assembly, and on the 16 and 32 bit platforms C. Putting these side-by-side and assuming roughly equivalent programmer competence levels at the time assembler would win out, C would get you to maybe half the speed of assembly on a good day and Forth was about 10x slower than that.<p>Which was still incredibly fast for the day, given that Forth was compiled to an intermediary format with the Forth interpreter acting as a very primitive virtual machine. This interpretation step had considerable overhead, especially in inner loops with few instructions the overhead would be massive. For every one instruction doing actual work you'd have a whole slew of them assigned to bookkeeping and stack management. What in C would compile to a few machine instructions (which a competent assembly programmer of the time would be able to significantly improve upon) would result in endless calls to lower and lower levels.<p>There were later Forth implementations that improved on this by compiling to native code but I never had access to those when I was still doing this.<p>For a lark I wrote a Forth in C rather than bootstrapping it through assembly and it performed quite well, Forth is ridiculously easy to bring up, it is essentially a few afternoons work to go from zero to highway speeds on a brand new board that you have a compiler for. Which is one of the reasons it is still a favorite for initial board bring-up.<p>One area where Forth usually beat out C by a comfortable margin was code size, Forth code tends to be extremely compact (and devoid of any luxury). On even the smallest micro controllers (8051 for instance, and later, MicroChip and such) you could get real work done in Forth.
Article is lame in multiple ways, and also eForth was written by Bill Muench. Dr Ting adopted Muench's version to use assembly language bootstrapping instead of metacompilation. Bootstrapping is possibly easier for beginners to understand, but metacompilation is part of Forth's fiendish cleverness and it's a shame for an aficionado to miss out on it.
What I like about Forth is that it can be expressed at the lowest level of computation, and that it can be used to bridge that to the highest level of computation. For example, Forth only requires about 12 opcodes to run, which can be implemented in a few dozen chips. But now that you have that, since it's Turing-complete, you can now pull across a lisp or C compiler, and build a working operating system from there. Granted, that would be a lot of work, but it's relatively straightforward work, and that's always impressed me.
I often use a heavily forth inspired script language in my bigger c# projects. I have a hidden repl and can input scripts. I like how easy it is to produce results with such low vocabulary. Also there is no expression parsing
This is a pretty good explanation. I think it maybe undersells the importance of the REPL a bit. (I'm not a Forth expert, but I did write StoneKnifeForth, a self-compiling compiler in a Forth subset, and I've frequently complained about the quality of Forth explainers.)
>I think it maybe undersells the importance of the REPL a bit.<p>Howo? Or would you agree that <i>value</i> is perhaps a more suitable word than <i>importance</i>? For me I think these articles have such a tendency to fixate on the strengths of Forth to the extent that they have reduced Forth to those strengths in the eyes of many. TFA does a fair job of avoiding this and shows Forth more as a powerful and flexible general purpose language than a very niche language, but I think it still focuses a bit much on the strengths at cost of the general.<p>You are a Forth expert compared to me and probably most of HN, so try and keep that in mind with your response if you could.<p>Edit: I am probably asking for insight into your workflow with Forth, but maybe not?
I like the spirit of this article, but I find it strange that they open their article by quoting me, but then don't include Dusk OS's C compiler in the list.<p>Fairly counting SLOC is a tricky problem, but my count is 1119 lines of code for the C compiler (written in Forth of course), that's less than 8x the count of chibicc, described as the smallest.
(typing from phone) i simply had not known. it is a great example of a short path to a c dialect then! merci pour votre travaille au dusk et collapse! i will add a paragraph about it to the essay. this took me many days to write and many revisions and still i see it isnt perfect!<p>note the point of that section was really that anyone using gcc or clang should ack. the real cost when using them.
That's a good point, thanks. How complete is it?
It's complete in sofar as being capable of compiling C programs, but it has a few quirks.<p><a href="https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/comp/c.txt#L53" rel="nofollow">https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...</a>
Possibly this is why it wasn't mentioned? There are enough differences in that list that I can't imagine any existing C library would compile unchanged.
> The "&&", "||" and "?:" operators do shortcutting.<p>is shortcutting different from short circuiting?
From what I can tell chibicc, unlike tcc, is not a complete c compiler in and of itself. Looking at its source code, it relies upon external tools for both x86_64 code gen and linking: <a href="https://github.com/rui314/chibicc/blob/90d1f7f199cc55b13c7fdb5839d1409806633fdb/main.c#L570-L573" rel="nofollow">https://github.com/rui314/chibicc/blob/90d1f7f199cc55b13c7fd...</a>
By design, it's not a fully compliant ANSI C compiler, so it's never going to be complete, but it's complete enough to, for example, successfully compile Plan 9's driver for the Raspberry Pi USB controller with a minimal porting effort.<p>So, Dusk's compiler is not apple-to-apple comparable to the other, but comparable enough to give a ballpark idea that its code density compares very, very favorably.
Came here to say exactly that, cc<< blows these numbers out of the water. Strange choice from the author.