Re: Why VAX Was the Ultimate CISC and Not RISC

On 3/11/2025 10:44 AM, MitchAlsup1 wrote:

On Tue, 11 Mar 2025 2:49:00 +0000, Robert Finch wrote:
 

On 2025-03-10 8:53 p.m., MitchAlsup1 wrote:

On Mon, 10 Mar 2025 22:40:55 +0000, BGB wrote:

------------------------

 

My 66000::
  00 0000000000000000..FFFFFFFFFFFFFFFF: DRAM
  01 0000000000000000..FFFFFFFFFFFFFFFF: MMI/O
  10 0000000000000000..FFFFFFFFFFFFFFFF: config
  11 0000000000000000..FFFFFFFFFFFFFFFF: ROM
>

How does one reference DRAM vs MMI/O at the same address using a LD / ST
instruction?

 The MMU translates the virtual address to a universal address.
The PTE supplies the extra bits.
 

Q+ CPU just uses a 64-bit address range. The config space is specified
in a CR defaulting to FFFFFFFFDxxxxxxx The TLB is setup at boot to
access ROM at FFFFFFFFFFFCxxxxx Otherwise there is no distinction with
addresses. There is a region table in the system that describes up to
eight distinct regions.

 Every major block in my architecture has ports in config space that
smell just like that of a device on PCIe having said control block.
My thought was that adding all these to the config name space might
cramp any fixed (or programmable) partition. So, the easiest thing
is to give it its own big space.
 Then every device header gets 1 or more pages of address space for
its own control registers. PCIe is now a 42-bit address space::
segment, bus; device; function, xreg, reg and likely to grow as
ACHI can consume a whole PCIe segment by itself.
 

Whatever you are trying to do, you won't run out of address space until
64 bits becomes insufficient. Note: all HW interfaces are in config
space
and all CRs are in MMI/O space.

>
Are there any CRs accessible with any instructions besides LD / ST?

 CRs accessible via HR instruction theoretically  == 40
CRs accessible via HR instruction at a privilege >= 16
 Basically, HR provides access to this threads critical CRs
{IP, Root, ASID, CSP, exception ctrl, inst ctrl, interrupts ...}
and has access to the CPU SW stack according to privilege.
 

------------

They seem to also be asking for a UEFI based boot process, but this
would require having a bigger BootROM (can't likely fit a UEFI
implementation into 32K). Seems that the idea is to have the UEFI BIOS
boot the kernel directly as an ELF image (traditionally UEFI was always
PE/COFF based?...).

>
Boot ROM should be big enough that no BOOT ROM will ever exceed its
size.
--------------

There is a probable need to move away from the "BJX2" name, which as
noted, has some unfortunate connotations (turns out it was also used for
a lewd act) and seems to be triggering to Google's automatic content
filtering (probably for a similar reason).

>
Coming up with names is surprisingly difficult. I got into a discussion
with a colleague a while ago about this. They were having difficulty
coding something an it turned out to be simply what names to choose for
routines.

>
Hilarious--and reason enough to change names.
>
When you do change names, can you spell LD and ST instead of MOV ??

>
Yes, please LD / ST it is so much clearer what is going on. Less trouble
getting confused by the placement of operands.
>
I always put the memory operand second, which breaks the pattern of
having the destination operand first. Otherwise the destination is
first.
>
I go cross-eyed reading code that is a whole lot of moves.

 I agree.

I wonder if the different preferences is at least partially due to whether the person has a hardware or a software background?  The idea is that when hardware guys see the instruction, they think in terms of register ports (read versus write), what is required of the memory system (somewhat different for loads versus stores), etc.  However software guys think of a language construct, e.g. X = Y, which is logically a move.  I don't know if this is right, but I think it is interesting.
A somewhat related question, if one wants to copy the contents of R3 into R2, is that a load or a store? :-)
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)