Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Sun, 2 Mar 2025 14:39:36 -0600
Organization: A noiseless patient Spider
Lines: 189
Message-ID: <vq2fmi$udn2$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar1.125817@mips.complang.tuwien.ac.at> <vq01oh$dq4s$1@dont-email.me>
 <2025Mar2.124623@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 02 Mar 2025 21:39:47 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a4cd612affcc1148eabb86759e7b6b28";
	logging-data="997090"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18w1ZWy09gHvxpWyompGnwebpdq97ZNTWQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:+BqAYGli1LsOrmkKlg26NidjASY=
In-Reply-To: <2025Mar2.124623@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 8621

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.

========== REMAINDER OF ARTICLE TRUNCATED ==========