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: Stephen Fuld Newsgroups: comp.arch Subject: Re: Why VAX Was the Ultimate CISC and Not RISC Date: Tue, 11 Mar 2025 11:15:06 -0700 Organization: A noiseless patient Spider Lines: 103 Message-ID: References: <2025Mar1.125817@mips.complang.tuwien.ac.at> <2025Mar1.232526@mips.complang.tuwien.ac.at> <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk> <2025Mar3.174417@mips.complang.tuwien.ac.at> <2025Mar4.110420@mips.complang.tuwien.ac.at> <2025Mar5.083636@mips.complang.tuwien.ac.at> <9371fe9be75cdd606c876f539e1d2d78@www.novabbs.org> <0da86de26bac1912b190793512255aa4@www.novabbs.org> <5e696219dedf30d0095dfd7671a4c87f@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 11 Mar 2025 19:15:07 +0100 (CET) Injection-Info: dont-email.me; posting-host="617d9ae2268289fad26cfbdea81af88e"; logging-data="2177962"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19V8RLLoHoJTjDj9BdyyzSKoOIqBAG3OLg=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:euXm9oBYI9Q3OFMpqz8h4y6FMFo= Content-Language: en-US In-Reply-To: <5e696219dedf30d0095dfd7671a4c87f@www.novabbs.org> Bytes: 6398 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)