Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Wed, 12 Mar 2025 01:09:12 -0500
Organization: A noiseless patient Spider
Lines: 463
Message-ID: <vqr8gm$2finh$1@dont-email.me>
References: <vpufbv$4qc5$1@dont-email.me>
 <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk>
 <2025Mar3.174417@mips.complang.tuwien.ac.at> <vq4qav$1dksd$1@dont-email.me>
 <vq5dm2$1h3mg$5@dont-email.me> <2025Mar4.110420@mips.complang.tuwien.ac.at>
 <vq829a$232tl$6@dont-email.me> <2025Mar5.083636@mips.complang.tuwien.ac.at>
 <vqdljd$29f8f$2@paganini.bofh.team> <vqdrh9$3cdrc$1@dont-email.me>
 <vqek6h$3fro6$1@dont-email.me>
 <fe70b48cd6fef0aaf89278163d8b6322@www.novabbs.org>
 <vqfmr4$3npgk$1@dont-email.me> <vqg04o$3p80h$1@dont-email.me>
 <vqgbao$3rbkh$1@dont-email.me>
 <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org>
 <vqnps4$1j63b$1@dont-email.me>
 <0da86de26bac1912b190793512255aa4@www.novabbs.org>
 <vqofeo$1qgv6$1@dont-email.me>
 <a3304eadd68c10acb8385c43e326f4ec@www.novabbs.org>
 <vqq9h2$260sm$1@dont-email.me>
 <7b773a3b32e98c7b836e2250b9fb728b@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 12 Mar 2025 07:10:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ea467a6533dff4efc0a3700c4fb8f733";
	logging-data="2607857"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+h74dbuq8WpE8X0PjuOfXVDrQe2iryqaA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:QjubfYnnS7mPzq1KlK3cui7szZI=
Content-Language: en-US
In-Reply-To: <7b773a3b32e98c7b836e2250b9fb728b@www.novabbs.org>
Bytes: 19452

On 3/11/2025 7:33 PM, MitchAlsup1 wrote:
> On Tue, 11 Mar 2025 21:20:22 +0000, BGB wrote:
> 
>> On 3/11/2025 12:57 PM, MitchAlsup1 wrote:
> --------------
>>> My whole space is mapped by BAR registers as if they were on PCIe.
>>>
>>
>> Not a thing yet.
>>
>> But, PCIe may need to exist for Linux or similar.
>>
>> But, may still be an issue as Linux could only use known hardware IDs,
>> and it is a question what IDs it would know about (and if any happen to
>> map closely enough to my existing interfaces).
>>
>> Otherwise, would be necessary to write custom HW drivers, which would
>> add a lot more pain to all of this.
> 
> There is already a driver in BOOT that reads config headers for
> manufacture
> and model, and use those to look up an actual driver for that device.
> I simply plan on having My 66000 BOOT up code indexed by Mfg:Dev.
> 

OK.


> --------------
> 
>>>>    Some read-only CSRs were mapped over to CPUID.
>>>
>>> I don't even have a CPUID--if you want this you go to config space
>>> and read the configuration lists and extended configuration lists.
>>>
>>
>> Errm, so vendor/Hardware ID's for each feature flag...
> 
> No, a manufacture:device for every CPU-type on the die. Then all of
> the core identification is found on the [extended] configuration
> lists.
> core kind
> fetch width
> decode width
> execute width
> retire width
> cache sizes
> TLB sizes
> predictor stuff
> ..
> 
> In practice, I expect some later phase in BOOT will read all this out
> and package it for user consumption (and likely another copy for
> supervisor consumption.) Then it is accessed as fast as any cached
> chunk of memory.
> 

As-is, a lot of this information is not available...


A lot of the feature flags are more things like whether or not the CPU 
supports Load/Store Pair or SIMD or similar.


>> 30 and 31 give the microsecond timer and HW-RNG, which are more relevant
>> to user-land.
> 
> The timer running in virtual time or the one running in physical time ??
> 

In the emulator, it is internally based on the virtual clock-cycle count 
(so, from its point of view, it seems accurate).

The emulator speed is then kept at roughly real-time based selectively 
running the VM based on whether or not the number of emulated 
clock-cycles is larger than the amount of clock-cycles that would have 
been executed given the external wall-clock time at the specified 
clock-speed.

Granted, this part isn't super exact regarding how closely things remain 
in-sync (but, on-average, it works).



There is also a separate "wallspeed" mode which basically runs the 
emulator as fast as it will go and uses the external wall-clock time 
instead (though with some internal trickery to estimate the microsecond 
values, albeit with the constraint that a later given time can't be less 
than a previously given time).

Partly this is because "actual wall-clock time" isn't super fine-grained 
(roughly millisecond territory on Windows), and the time within emulator 
isn't too closely tied to real-time (it roughly extrapolates and guesses 
based on how quickly the emulator is running in this mode).

This mode also disables some of the modeling usually used to try to keep 
things cycle-accurate (such as modeling L1 and L2 cache hits and misses).



For the Verilog partial simulation, it is based on clock cycles. So, it 
will drive the main clock at 50MHz, but also drive a 1MHz clock.

For the full simulation (and FPGA), there is a module that turns the 
input clock into various lower-speed clocks, such as 1MHz (for the 
microsecond timer, and 2Hz for the cursor and blinking text effect).


Note that the main PLL turns the 100MHz master clock into 100, 50 and 
75MHz and similar.

Most other lower-speed soft clocks are based on fractional accumulation 
timers.

Well, except for things like the SPI clock, which are based on 
decrement-division, which give a limited range of values on the fast-end:
   50, 25, 16.7, 12.5, ...

But, faster clocks via an accumulation timers gives very jittery output 
(so, they are better for lower-speed clocks, such as for driving audio 
output or RS232).


>> 32..63: Currently unused.
>>
>>
>> There is also a cycle counter (along vaguely similar lines to x86
>> RDTSC), but for many uses a microsecond counter is more useful (where
>> the timer-tick count updates at 1.0 MHz, and all cores would have the
>> same epoch).
>>
>> On x86, trying to use RDTSC as a timer is rather annoying as it may jump
>> around and goes at a different rate depending on current clock speed.
> 
> By placing the timers in MMI/O memory address space*, accesses from
> different cores necessarily get different value--so the RTC can be
> used to distinguish "who got there first".
> 
> MMI/O space is sequentially consistent across all cores in the system.
> 

When it is driven by a 1MHz clock with a shared epoch across all cores, 
MMIO is unnecessary.

Granted, if one wants to time the relative ordering of events between 
CPU cores, a 1MHz clock may be insufficient, even at 50MHz.


> ------------
>> This scheme will not roll over for around 400k years (for a 64-bit
>> microsecond timer), so "good enough".
> 
> So at 1GHz the roll over time is 400 years. Looks good enough to me.
> 

The microsecond timer is ideally independent of clock-speed.


>> Conceptually, this time would be in UTC, likely with time-zones handled
>> by adding another bias value.
> 
> What is UTC time when standing on the north or south poles ??
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========