dewster

That's me actually! :-)

AFAIK Carolina only uses the D-Lev pitch circle for coming in on pitch, not for active playing. That's pretty typical for players who have learned on an analog Theremin, where they have necessarily been guided only by fingering techniques and their ears. Many Thereminists plug a guitar tuner or similar into their Theremin for this, but those sorts of tuners are rather sluggish. When you have a highly responsive tuner, then playing turns into an almost "paint by numbers" experience, and you are much more aware of the key and other song structure.

There are 50 or so kits spread out all over the world, some in the hands of the world's best Thereminists, which has been quite gratifying. But the project has been in a bit of a hiatus while I do more R&D, and the current tariff situation isn't exactly filling me with enthusiasm. Enclosures and antennas have been a burden for some, a wine box build is probably your best bet. I don't mind supplying hand-wound coils and any guidance you may need. My contact info is on the support page.

The D-Lev has a fairly extensive MIDI implementation, and you can control any CC with the volume hand (7 or 14 bits), so perhaps something like this would be possible if the synth it's driving is flexible enough.

Manual: https://d-lev.com/support/D-Lev_Manual_2024-01-08.pdf Processor: https://d-lev.com/research/Hive_Design_2022-10-24.pdf

Here's Carolina playing the D-Lev: https://www.youtube.com/watch?v=0vjJ2SG5cVA

She's a super sweet person, and a consummate musician!

The "digital one" Carolina refers to is my open source D-Lev design: https://d-lev.com/

The problem with trivial ops like stack manipulations is that they don't really do anything useful, but they can take as long as multiply in the pipeline.

Stack machines made more sense when memory was limited (small opcodes) and there were no hardware multiplies, but these days they make no sense.

I don't understand all the vague nostalgia for something that never could have panned out outside of the creaky old Apollo flight computer or something.

A stack processor will always be less efficient than a two or three operand register-based processor. This is because all of the the registers can be used directly without any stack manipulations to access them, and the two or three operand operations usually include a move.

If you examine any stack language code, you should consider any stack manipulation to be a NOP type of inefficiency. And when a virtual stack machine is implemented on non-stack hardware, these inefficiencies are compounded.

"...and given each chip has 144 entire computers on it..."

Entire computers? What decade is it again?

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.

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.

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).

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.

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.

If you actually look at the way Forth works you'll see that every stack manipulation wastes code space and real-time. Since there is only one data stack there are a lot of stack manipulations going on. Forth programmers are aware of this and do their best to minimize them, which tends to make their incredibly cryptic code even more cryptic.

If the definition of a low level language is one that bedevils the programmer with minutiae, the Forth is the lowest of the low. I don't understand the fascination others have for it, and don't understand how anyone can like it after actually programming with it. It's horrible.

Developing on the target is just so last century. Now that programmers have developed the IDE you'll have to pull them from their cold dead hands.

Both. And under the hood, Forth implements a virtual stack machine on top of a non-stack machine, which is inefficient.

I guess I'm just trying to counter all the mythos and happy talk surrounding Forth and stack processing in general. In the end Forth is a highly (too?) simplistic language, a product of its time, and nothing all that special or powerful. It does a lot of stuff poorly and the code tends to write-only. The syntax is so loose that the entire dictionary has to be searched to know you're dealing with a number. It's no mystery that we aren't all coding on it now.

It's called factoring with subroutines, and Forth hasn't cornered the market on anything by calling them words.

I don't think the stack in a traditional languages is the same as stacks in stack machines and languages. It's a lump of memory that gets allocated to a thread for stuff, and the allocation is indeed done in LIFO fashion, but I believe access to individual memory locations in the allocation is random. Name is the same, LIFO and all, but the mechanism granularity makes it quite different.

Pure stack machines don't have local variables. They have at most two stacks and that's it.

THE central problem with pure stack machines and stack languages:

The programmer knows in their heart that moves, swaps, dupes, drops, etc. - any stack manipulation that doesn't involve a functional change to the data itself - is an inefficiency to be minimized, but this effort isn't in any way related to the problem at hand (writing a program to do something) so it's unwelcome mental overhead.

I like puzzles as much as the next person, but not so much when they seriously impede the solving of a bigger more serious puzzle, nor when the sub puzzle solving is an exercise in the minimization of something bad rather than the elimination of it.

I agree. Not trying to be racist, but I find that British authors are quite often unnecessarily verbose, so I'm somewhat gun shy when picking up their books.

One notable exception to this observation is Douglas Self, who writes thick, incredibly useful, highly detailed, and remarkably entertaining books on audio circuitry design. They read almost like good novels.

Again, I'm most likely an idiot, but I'm just not seeing it in any of the examples I've encountered. Not trying to be dense, I realize the onus is mostly on me here, and I really am interested in fundamentals. Just wondering if there is a better example of why I should go out of my way to understand lambda calculus, cause this one ain't cutting it. LC may well indeed form the basis of everything CS - if so why doesn't it seem very impressive at first (and second, and third) sight?

Your initial words were "Here is how you can use the lambda calculus to compute factorials in non-geological time" which led me to believe you were claiming LC was a very (the most?) efficient route to factorial calculation. Which would make me sit up and take notice were that the case.

I'm sorry to say that your factorial example just seems painful and pointless to me, and doesn't encourage me to expand my mind via LC at all.

If we were playing the Hot and Cold game you would be getting colder.

Are you telling me that the most efficient means of generating factorials is via LC? That no other method can touch it in terms of real time?

Thank you for expressing that better than I could ever do. Outside of JS sucking but being saved by extensibility, and academic interests, I've never heard a concrete reason why LC is important in a practical sense to most programmers. Can't swing a dead cat on the internet without hitting an LC article lately, and I really don't get the sudden interest and insistence that we all must learn it.

Looking into LC I was led to Curry's Paradox, the natural language version being "If this sentence is true, then Germany borders China" which (again, I'm probably just an idiot) doesn't strike me as paradox material.

This isn't some random reverse snobbery rant, I'm all for digging deep and really understanding things (I do this all the time, probably more than most engineers). But I can't see the Emperor's clothes everyone seems to be admiring, and it isn't for lack of looking.

OMG, that's insane (in a bad way). Stacks exploding, hours of optimization, all for a simple factorial (toy problem). Exciting I suppose for a few souls in academia who spend their lives writing papers about theoretical stuff (not that there's anything wrong with that).

I'm probably showing my profound ignorance, but what has lambda calculus done for me lately? It seems to be an abstract formalism of some sort, but I've yet to see any real use of it, the examples are baby step type stuff with obfuscated syntax.

CS seems overburdened with jargon and trendy crap (IMO) so is this just the latest thing coming down the pike that everyone needs to give lip service to in order to seem smart to their peers?

Altera Quartus has supported SV (SystemVerilog) quite well for some time now. I tend to work in 9.1sp2 as that was the last version of Quartus with integrated simulator (waaa!).

Xilinx requires you to use their newer tooling in order to write in SV. As these tools tend to be incredibly bloated, this is a disadvantage IMO (you want to use the earliest and therefore least bloaty tool that does the job).

I started out in VHDL and was forced by the other person on the "team" to learn verilog for a project. As with ANY language, you end up trying a bunch of stuff out to see how things are implemented, what breaks, etc. in order to get your footing. Over time I grew to appreciate the C like nature of verilog - its reduced verboseness over VHDL makes it an easier language to get actual things done in. And it makes switching between C and verilog pretty natural.

I resisted looking into SystemVerilog for forever as I was under the impression that it was more of a systems verification thing, but it is actually just plain old verilog with some incredibly useful extensions for synthesis. The package system is really, really nice. Look online for papers by Stuart Sutherland. No language is perfect, and there are things I would change in SV (support for negative bit indices, less awkward sub vector select, etc.) but SV comes closest to the ideal HDL IMO. HW design via HDL is fascinating, and a strangely small space for the times we live in.

Using high level languages to do clock-based concurrent stuff is IMO insane as it just adds to the chain breakage, and few will be trained and able to easily use the source. Would you listen to anyone who proposed a VHDL to Haskell converter for writing everyday conventional software? HDLs are close to the metal for a reason.

From the article: “Caches and virtual memory as they are currently implemented are some of the worst design decisions that have ever been made,” Sohmers boldly told a room of HPC-focused attendees at the Open Compute Summit this week.

As a lay processor designer, I couldn't agree more. I don't like VLIW, but this architecture makes a lot of sense. I think it took up to this point for compiler technology to catch up with what is possible in hardware.

Almost all the good ideas in computing were mined out long ago, the trick I think is to get the computing world to give up on those which are holding things back (cold dead hands if necessary).