There are loads of systems where every button and encoder has many functions, with modal or paged interfaces. But I'm trying to stick to a model of no hidden or ephemeral state with my modular, just for fun, I guess. Mostly analogue, so no non-volatile memory to store settings, the positions of the patches and knobs set everything, and the test is that if I power it down and back up it must come back doing what it was doing when the power went out (very long cycle lfos notwithstanding!)
When a laptop can simulate anything, the physicality of the interface is most of the attraction, so might as well go all the way...
For sure! The interface is the most important part these days when practically everything can be emulated.
In my design, I wouldn't say the state is hidden though—that's the point of having an indicator light with every parameter. The LED becomes the state visualization. So, write-wise, yes, it's overloaded, but read-wise it's not.
I'm just now realizing I didn't explain that well in the OP, lol. And really this is more of a budget-friendly approach, rather than a user-friendly approach. I'm trying to meet those half way...
I remember in the very early days as a hobbyist working with cgi perl scripts for forums or guest books where the script just edited the "static" content in place.
The script would write new html files for new posts and do "fun" (I mean, terrifying) string manipulation on the main index to insert links to posts etc. Sometimes they used comments with metadata to help "parse" pages which would see edits.
These both were, and definitely were not, "the days" :D
Catches me every time too. And it's so quick. You can go in to a shop to pick up a packet of crisps thinking it's daytime, but actually is quarter past 6, so you come back out and it's full dark!
I'm in the southern UK, and I'd take our late-May/early-August "it's light while I'm awake and dark while I (should be) asleep" all year round if I could get it.
You could become peripatetic and seek out the spot of opposite latitude during the dark season. So you could have 15 hours of daylight, 12 hours of daylight, then 15 hours of daylight again. I've thought that with idle rich amounts of money I'd get a very large yacht and sail the pacific rim in time with the seasons, perpetual spring, summer, spring, summer.
We have different definitions of rich. It's not just the cost of living. It's also the time and to deal with the governments to allow this, it's having the money to spend the time, it's the job that allows this, it's the time away from family not being catastrophic for someone's wellbeing. Frankly, this is vastly infeasible for 99% of people. I'd easily consider the remaining 1% "rich" in some way
Unfortunately there are lots of materials run through a table saw which can trigger a sawstop. A false positive destroys the blade. Decent blades cost several hundred dollars, and are intended to be resharpened and last for many years.
I belong to a community hobbyist workshop. There are a lot of rules, lockouts and a key in place around the table saw usage, but they won't install a sawstop because they can't afford to keep up with the wasted blades.
Personally, I think I'd rather have one, but I can absolutely see why people would disable them if they were mandatory.
Have you read Infinite Jest? Barely any of the book is really about it (the actual theme being a study of addiction is many forms), but the ostensive premise is that a video clip has been created that's so compelling that it's impossible to stop watching it.
Some of the asides are also hilariously/terrifyingly prescient. The passages on the evolution of video calling are some of my favourites.
I've been to enough boutique hotels in the Netherlands with clear glass doors from bedroom to bathroom to say that probably wasn't a "future" thing, just a Dutch thing...
Because then it would need more registers for the other purpose?
But actually the decision about which general purpose registers to use for what is made at compile time (hence we're discussion a compiler flag here, the frame pointer is not a hardware dictated feature), so the question is actually kind of moot. If the compiler is out of registers to allocate and instead uses the stack, the CPU isn't reasonably going to be able to undo that.
Sure, but wouldn’t it make sense to extend the instruction set to allow the compiler to use these registers instead of reserving them for speculative / out-of-order execution? It was just a thought i had after watching a talk by a compiler guy: https://youtu.be/2EWejmkKlxs?feature=shared&t=2409
jcranmer got it right. Read that reply (and mine). And then maybe rewatch watch Chandler Carruth says.
The current practice allows for CPUs to transparently increase their physical register count (to gain performance) and still run old code -- and older CPUs can still run new code. That's usually quite practical...
Adding more register names takes more bits for the register numbers -- which leads to larger instructions. It also leads to more complicated encodings if we want backwards compatibility. AMD64 does that by adding an optional prefix byte that carries a payload of 4 more instruction bits. That's one bit each for the three possible register names encoded in a traditional IA32 instruction + a bit to indicate whether to operate on 32-bit or 64-bit data (the actual rules are a bit more complex). Intel published a whitepaper recently suggesting a future encoding with a different (optional) prefix that encodes 8 more bits -- so each of the three register names can be extended to 5 bits (32 register names). It all ends up being quite complicated + new code won't run on older CPUs, which is not great.
I think you are suggesting not just bigger register names but also doing away with register renaming -- that would be... less than entirely useful because you would lose almost all your out-of-order capability and thereby almost all your ability to hide cache misses. Cache misses are very, very hard to predict statically (before actually running the code on a real CPU with real data) so good luck trying to do magic ahead-of-time allocation of those registers...
It's an ML story. The article specifies that the current (now previous?) state of the art models are numerical, crunching vast equations representing atmospheric physics.
When a laptop can simulate anything, the physicality of the interface is most of the attraction, so might as well go all the way...