Re: Why VAX Was the Ultimate CISC and Not RISC

On 3/2/2025 5:46 AM, Anton Ertl wrote:

BGB <cr88192@gmail.com> writes:

It almost seems like they could have tried making a PDP-11 based PC.

 I dimly remember that there were efforts in that direction.  But the
PDP-11 does not even have the cumbersome support for more than 64KB
that the 8086 has (there were PDP-11s with more, but that was even
more cumbersome to use).
 

I had thought it apparently used a model similar to the 65C816.
Namely, that you could address 64K code + 64K data at a time, but then load a value into a special register to access different RAM banks.
Granted, no first hand experience with PDP-11.

DEC also tried their hand in the PC-like business (DEC Rainbow 100).
They did not succeed.  Maybe that's the decisive difference from HP:
They did succeed in the PC market.
 

I guess they could have also tried competing against the Commodore 64 and Apple II, which were also popular around that era.
No idea how their pricing compared with the IBM PC's, but in any case, those who had success were generally a lot cheaper.
Well, except for the Macintosh apparently, which managed to survive with its comparably higher costs.
Well, and the cheaper Apple IIGS, which died off, but was apparently hindered by MOS having poor yields for the needed CPUs (but, I do remember having messed around with a IIGS back when I was in elementary school; though most of the PCs around the school at that time were running Windows 3.x).
I was odd though, in middle school, rather than running Win9x, I ran NT4, before jumping to Win2K and using this in high school (with most PC's at this time running Win98).
But, before that, most computers were DOS + Win 3.11 or similar.

DEC could have maybe had a marketing advantage in, say, "Hey, our crap
can run UNIX" and "UNIX is better than DOS".

 That was not what customers were interested in.  There were various
Unix variants available for the PC, but the customers preferred using
DOS, which was preinstalled and did not cost extra.  And even when you
could install Unix for free in the form of Linux, most customers just
used Windows which was preinstalled, and (probably decisively) for the
network effects).
 

Presumably they could have had freely pre-installed Unix?...
Then again, I think by this point, AT&T had started asking for licensing fees for original Unix variants.
I think also BSD was a little later in the timeline, running on 386-based systems and them mostly competing with Linux.
There is presumably a non-zero Unix influence on Windows given that the binaries were basically COFF with an MZ stub glued on.
Well, and my variant goes partly the other way:
Drops the MZ header and mostly LZ4 compresses the binary;
But, not using LZ to save space, but rather to increase loading speed.
Though, the Boot ROM's LZ4 decoder still isn't particularly fast (it is up there with reading data from the SDcard; but I also need to care about code footprint in this case). Mostly matters in Verilator (time spent waiting for the kernel to load).
Though, ironically, did end up reworking Doom's loader code, mostly to make it not take a whole day to load in a Verilator sim:
Rather than trying to load all of the textures and sprites up-front, it now merely initializes placeholder arrays, and does the actual loading lazily.
Maps generally only use a subset of the textures and enemies, so it works out faster to load them as they are encountered (though, does add a certain amount of jitter as things are loaded in, *). A possible "ideal" way could be to "prefetch" things at map startup, but with Doom this would add complexity.
*: The first time the player "sees" a given sprite or a linedef with a particular texture, it gets demand loaded. Not taking a full day of simulation to start up beats having a certain amount of demand-load jitter.
Likely "fix" here would be to add something to go at map load-time, and for every linedef texture, probe that it is loaded, and for every "thing", check if sprites have been prefetched for that type, and if not, prefetch them.
Could maybe also add something to demand-load the sound effects.
Can note that Quake had used a different strategy:
It loads everything used for a given map, for every map load, with no caching of game assets whatsoever. So, it uses a sliding, stack like "Hunk" allocator, mostly relegating the Doom style "Z_Malloc" allocator mostly to handling HUD graphics and similar.
Though, Z_Malloc did have the notable limitation that it needs to reserve all of its memory up-front, rather than growing the heap in chunks like most other "malloc" style allocators.
The TestKern malloc also has some overlapping features with Z_Malloc, but one feature that plays a role in Doom is absent:
With Z_Malloc, memory allocations could be tied to a pointer, where if the alloc is freed, this pointer is NULL'ed automatically.
Though, in theory, it can be faked:
It can assign type-tags to memory allocations, and can register finalizer callbacks for these type tags.
So, one could make an object type that has this pointer-to-pointer and NULL's the associated pointer if the finalizer is called (and then possibly breaks stuff if the memory holding the pointer manages to get freed before the finalizer gets called).
Though, generally, in TestKern, auto NULL'ing on zone-freeing was not really a thing.
Then, random occurrence:
I often use VLC as a background music player;
Whenever it changes songs/videos, it momentarily grabs keyboard input;
Last night, it managed to capture input as I was typing something, it did something, but happened quickly enough that I didn't see what exactly...
Then, it seems apparently, it had gone and added all the "Sonic Rush" music to my playlist. Encountered it, was like, "OK, whatever, haven't heard this in a while, will let it play."
After a little while, was getting a bit old, checked it; seems it was set to loop the same song for a good part of an hour (of which I had sat through a little over 10 minutes).
But, yeah, can note that there are different properties for songs that are "listen once, and done" vs "works well if played in a loop". If one has too many "catchy" features, this can work well in a one-off song, but can quickly become annoying if it is played in a loop.
Say, for general suitability to looping background music:
   Poor:
     Hip-Hop
     Swing Jazz
   Meh bad:
     Disco style
     Rap
   Neutral:
     Butt metal
     Lounge Jazz
   Better:
     A lot of classical;
     Instrumental;
     Rave or EDM.
Stuff works OK between 120 and 180 BPM, probably better off not going too much over 200 BPM. Also preferable if things like vocals or other "distinguishing elements" are avoided, ...
So, yeah, probably better off just getting some super generic rave beats or similar and going with that.
Well, or failing this, the sound of over-driven speakers going "thump thump thump thump", which is seemingly sufficient to imply that loud music is being played, without any actual music being played (like, say, it is a 1 second looped stock sound effect, but no one really notices...).
Though, this is maybe going to far in the opposite direction.

- anton