[dewster]

I would argue that a language targeting bare metal type applications should at least be minimally aware of that underlying hardware. A single stack "virtual machine" type language is generally a terrible fit for the 2 and 3 operand register-based processors which dominate the landscape.

Every interview of Chuck Moore that I've read has contained zero push-back for his rather wild claims. It's entirely possible for an industry to do go down the wrong path for a while, but at some point, if Forth and stack processing were the giant killers they were cracked up to be, you would see them enter and dominate at least some portion of the mainstream. You can't say they haven't been given enough time.

It seems there are many "Forth curious" programmers out there, but they aren't being given the full picture with the various puff pieces and vanity projects floating around that never really go anywhere. It's almost a culture of victimhood.

[throwaway17_17]

I’d say calling a stack-based VM terrible is overstating the case a bit. In [1] the number seem to bear out that converting from stack-based to register-based yields an average, adjusted performance increase of approx. 25%. Also the transition results in an increase of code size of approx. 45%. That speed up is a non-trivial amount, but so is the code size increase, which is a valid area of concern for embedded/resource constrained engineering. Also, while I tend to STRONGLY agree about awareness of hardware at the language level (although I don’t think this should be limited to just embedded environments) the methods in [2] are automated and simple ways the Compiler can take stack-based code and create optimized register-based instructions.

As an aside, there is probably a different argument to had about whether a stack-based VM as the mental model of a language is beneficial, but as a said, that is a vary different argument than discussing the technical ability to transpire a stack-based VM to a register-based one.

[1] ‘Virtual Machine Showdown: Stack Versus Registers’. Ertl, Gregg, et al. 2005. https://www.usenix.org/legacy/events%2Fvee05%2Ffull_papers/p...

[2] ‘Implementation of Stack-Based Languages on Register Machines‘. Ertl, Dissertation. 1996.

[dewster]

I briefly skimmed [1] and their more sophisticated translation to a register VM yielded a 25% increase in code size, and not the 45% you stated? Regardless, VM to VM really isn't my point.

I still don't get the positives of why the programmer should be presented with a stack machine SW model when there is no stack machine type stack to be found in the HW. Programmers with no stack machine / language experience probably think (as I did at one point): "the stack on my HP calculator stack works great, why not base a language on that?" but it scales poorly, it gets really hairy if the stack is the only place to store things, and it's a major headache keeping the stack from going out of sync (hence Forth's clear I/O comments regarding subroutine stack use).

[throwaway17_17]

You are correct about the 25%. That was a mistake (for anyone else looking, the 45% was a decrease in the executed instruction amount from stack to register.

Correction aside, I, at some level, agree with you. The question of appropriateness/benefits of a SM model is different than considerations of the effectiveness of the code. In terms of the Forth SM model and its explicitly imperative model, I am familiar with the various complaints/arguments/critiques for varying reasons. I certainly acknowledge there is at least some burden placed due to the stack mechanics. I happen to be particularly attracted to the approach and enjoy programming that way, but that is just a preference of mine. However, I also tend to look at Forth as imperative language with which to program in what Backus describes as ‘function level programming.’ I find the benefits as listed by Jon Purdy, author of the Kitten language, in his talk about concatenative code to be compelling enough that exploration and refinement of this idea space to be valuable.

All that said, I am perfectly willing to consider that, as presented in Forth and presumably in the proposed language, SM mechanics and models are a hurdle for users of the language.

[kick]

In almost every meaningful interview of Moore, he explains the concept of virtual stacks. In his most recent interview, he literally explained how he designs all of his chips to have 8 physical stacks, while in the past he used (I believe) 16 stacks. You're misrepresenting Moore's claims in a way that can't be taken as anything but uninformed.

[7thaccount]

I believe there has been a wide variety of successful Forth projects including NASA probes.

Forth makes more sense when you can be like Chuck and design your own hardware. At that point Forth is more of a minimalist stack-based philosophy that consists of the minimal hardware + software design to accomplish something.

Is his way better? It likely has somewhere near the bare possible code and is very efficient system wise. If you wanted a minimal solution and could devote years to the project, then this is nice.

Does it make the best usage of developer time? Obviously not in many cases. In today's business world, you just slap some components together, do minimal acceptable testing, push it out and go to the next thing. Cost is important to the customer, so as long as somebody is willing to do that kind of work, everyone has to. Of course the downside is that we've accreted all this tower of abstractions and complexity going from OS to JVM to libraries and source. We already have tons of COBOL that can barely be maintained. Next will be the large Java and Python codebases.

[dewster]

The Forth success stories tend to be really, really ancient, and therefore almost irrelevant. Much like Chuck's arguments for the merits of stack languages / machines. Processor pipelines have to be at least deep enough to do a wide multiplication or you're basically looking at a toy.

I actually have designed my own FPGA soft core barrel processor, it's a special blend of register and stack machine. The blend occurs by placing stacks under the registers themselves. I believe this allows a low register count, 2 operand architecture to be more efficient than it otherwise would be, which minimizes opcode size, and sidesteps most the crazy you get when trying to shoehorn most processes into a single stack environment.

But has clear downsides as well, the main one being the stacks can become easily corrupted by any process using them - this is true of any stack machine but you strangely never hear it come up in conversations with Forth types. Stack processors can eliminate much traditional processor state, but the stacks themselves contain state, which is often overlooked.

[7thaccount]

Have you seen his Green Arrays? Not sure what the best use case is, but primitive it ain't.

[dewster]

Multi-core F18A technology, each of which is a simple 18 bit processor. IMO, anything less than 32 bits (with internal 33 x 33 = 65 bit multiply) falls into the primitive category abyss.

Moore is an incredible salesman, I'll give him that.

[kick]

Moore is an awful salesman but a skilled technologist, you have it reversed. He only recently got buyers for his recent processors, and he doesn't handle sales in any of his business endeavors.

Also, the chips he made before GA were 32-bit. He deemed it unnecessary, and the GA chips run miles around them.

[dewster]

I meant that he's a genius at the whole stack machine / language shaman thing.

32 bits are unnecessary?!? I suppose a 18 bit machine would run a lot "faster" than a 32 bit machine given certain data sets and loads, but I wouldn't want to do any audio DSP with it.