2026-06-04 00:49:43 <xentrac     > yeah, I think registers in a register file generally are random access, and the 3-to-5-bit field in an instruction that selects them is indeed their address
2026-06-04 00:50:45 <xentrac     > it's just that usually they don't support indirection, like IIRC the HP-38E user-land language didn't support indirection for its RAM
2026-06-04 00:51:29 <xentrac     > but for example the registers on the MuP21 weren't random-access memory
2026-06-04 01:46:25 <MrMobius    > 8051 has four sets of 8 bit registers that are all memory mapped. you can access them directly if you know which set is currently being used
2026-06-04 01:46:36 <MrMobius    > also memory mapped accumulator!
2026-06-04 01:53:48 <xentrac     > yeah, older computers commonly had their architectural registers in the linear address space.  the PDP-1 and PDP-10 were like that too
2026-06-04 01:54:04 <xentrac     > difference is there are a heck of a lot more 8051s still in use
2026-06-04 01:57:16 <xentrac     > Chifir takes this to the extreme: its instructions have two 32-bit source address fields and a 32-bit destination address field
2026-06-04 01:59:23 <xentrac     > so every memory address in the 4-gibiword address space is equally an accumulator
2026-06-04 03:16:50 <tabemann    > IMO referencing absolute addresses for things other than function calls isn't very useful, as most other operations will be on a set of variables which are actively acted upon in registers and otherwise stored in a stack
2026-06-04 03:17:29 <tabemann    > so you'd end up simply wasting a lot of space that way
2026-06-04 03:17:35 <tabemann    > 32 registers is generally enough
2026-06-04 03:24:00 <xentrac     > it's all situational
2026-06-04 03:25:00 <xentrac     > Chifir's primary objective is simplifying the specification of the hardware down to a single easy-to-implement page; wasting space is inconsequential
2026-06-04 03:26:07 <xentrac     > and the 8051 only has 32 8-bit registers in all four banks put together, IIRC?  Or are they 64?
2026-06-04 03:26:27 <xentrac     > no space for a stack really
2026-06-04 03:26:33 <tabemann    > I've never worked with the 8051 myself, and hope to never do so
2026-06-04 03:26:42 <xentrac     > haha, don't blame you
2026-06-04 03:27:21 <tabemann    > I primarily work with ARM Cortex-M, even though I'm slowly working on a RISC-V port of zeptoforth
2026-06-04 03:27:51 <tabemann    > (even though I'm kinda blocked because RISC-V's interrupt model is, well, rather inconvenient)
2026-06-04 03:28:28 <xentrac     > you may be interested to know that the QingKe core used in the CH32V003 and '006 uses its own alternative interrupt model
2026-06-04 03:28:42 <xentrac     > although I don't know if those chips are too small to be of interest to you
2026-06-04 03:28:58 <tabemann    > I suspect every practical RISC-V chip out there uses its own model
2026-06-04 03:29:29 <xentrac     > maybe yeah
2026-06-04 03:29:40 <xentrac     > although the standard model is probably the lowest transistor count one
2026-06-04 03:29:40 <tabemann    > e.g. the RP2350 has support for two models, a very basic, rudimentary one based on the 'default', and its own Hazard3-specific one
2026-06-04 03:29:55 <xentrac     > CNLohr published this absolutely astounding video about the CH32V006 the other day: https://www.youtube.com/watch?v=1vs_WxC2Odo
2026-06-04 03:30:07 <tabemann    > sorry, I don't do videos
2026-06-04 03:30:22 <xentrac     > he implemented a roughly-2-nanosecond precision time-domain reflectometer in software on the chip
2026-06-04 03:30:49 <xentrac     > videos are a reasonable thing to not do; they can be an attractive nuisance
2026-06-04 03:31:13 <tabemann    > the only kinds of videos I do are music videos, films, and murder mysteries
2026-06-04 03:31:18 <tabemann    > especially foreign ones
2026-06-04 03:31:47 <tabemann    > vlogs though... no
2026-06-04 03:32:26 <tabemann    > but yeah, I've been spoiled by the ARM Cortex-M interrupt model
2026-06-04 03:33:48 <xentrac     > unfortunately he doesn't seem to have published the TDR source code on his GitHub or written about it on http://cnlohr.net/projects.html
2026-06-04 03:34:12 <xentrac     > and it's probably hard to convey the sense of wiggling oscilloscope traces in those media anyway
2026-06-04 03:58:03 <Stalevar    > tabemann, does the RISC-V on rp2350 support MMU or it's very minimal cores smaller than even M33?
2026-06-04 03:58:49 <Stalevar    > And what is the point of RISC-V ISA besides it being royalty-free for core designers?
2026-06-04 03:59:14 <tabemann    > I'd be very surprised if RISC-V on RP2350 supported true MMU
2026-06-04 03:59:44 <tabemann    > the point of RISC-V is also that you can extend it as you see fit, within the practical limits of the ISA
2026-06-04 04:00:05 <tabemann    > whereas ARM doesn't allow you to just go and modify the underlying architecture
2026-06-04 04:09:31 <xentrac     > Stalevar: most ARM licensees are very limited in what they can adapt about the chip
2026-06-04 04:09:39 <xentrac     > well, about the CPU
2026-06-04 04:17:05 <tabemann    > a good example of this is how with the RP2040 RPi couldn't just add DIV and UDIV instructions to the ARM Cortex-M0+ cores
2026-06-04 04:17:27 <tabemann    > rather they had to work around the restrictions of their license by making divisor peripherals
2026-06-04 04:22:09 <Stalevar    > But you said rp2350 RISC-V cores are less capable than M33, right? Then is there any point to use it outside "ideological"?
2026-06-04 04:23:02 <Stalevar    > Why not to make an RISC-V only core which is as cool as MCU but is capable of running full-fledged linux and drive DDR2 or 3?
2026-06-04 04:23:25 <xentrac     > well, being able to add DIV and UDIV instructions seems like a pretty practical benefit
2026-06-04 04:23:30 <Stalevar    > Or find SRAM which goes at least up to 64M so it can run linux without cramming it down too hard
2026-06-04 04:23:58 <xentrac     > you could argue that in general any kind of conflict between people is "ideological", and this is a conflict between ARM and the Raspberry Pi Foundation
2026-06-04 04:24:18 <Stalevar    > No, I mean practical considerations
2026-06-04 04:24:30 <Stalevar    > Doesn't RP2350 have division?
2026-06-04 04:24:45 <tabemann    > the reason why they added RISC-V to the RP2350 is essentially that they were significantly under their silicon budget so they figured "why not?"
2026-06-04 04:24:54 <tabemann    > the RP2350 has DIV and UDIV
2026-06-04 04:24:58 <tabemann    > the RP2040 does not
2026-06-04 04:25:29 <xentrac     > another practical reason to use RISC-V is that you can get a whole CPU into 200 4-LUTs: https://github.com/olofk/serv
2026-06-04 04:26:00 <tabemann    > even though I have heard unsubstantiated rumors that RPi may be preparing for a RISC-V only RPi Pico 3 in the future
2026-06-04 04:26:48 <xentrac     > another is that a lot of RISC-V cores seem to use significantly less power than similarly-powered ARM cores
2026-06-04 04:27:20 <xentrac     > like, when GigaDevice came out with the GD32VF103, it used a lot less power than the GD32F103, which was the same peripherals but with an ARM core
2026-06-04 04:27:34 <xentrac     > an already-power-optimized ARM core
2026-06-04 04:28:06 <tabemann    > however, one downside of RISC-V is that its standard interrupt model is crap
2026-06-04 04:28:16 <Stalevar    > I guess backward compatibility weights it down
2026-06-04 04:28:18 <xentrac     > another is that if you're using compressed instructions your system is a lot easier to debug at the assembly level than ARM32 cores that support both compressed and uncompressed instructions
2026-06-04 04:28:30 <xentrac     > which *is* a backward compatibility question
2026-06-04 04:28:33 <tabemann    > RISC-V's core instruction set is tiny
2026-06-04 04:28:38 <tabemann    > yet powerful
2026-06-04 04:28:44 <xentrac     > "powerful"
2026-06-04 04:28:53 <xentrac     > it's boring and usable
2026-06-04 04:29:38 <tabemann    > I'm contrasting it with ARM Cortex-M, which piles on the instructions
2026-06-04 04:29:50 <xentrac     > I think it would really benefit from a few of those instructions
2026-06-04 04:30:18 <tabemann    > ARM Cortex-M3/M7/M33? those have tons and tons and tons of extra instructions that probably aren't necessary
2026-06-04 04:30:23 <xentrac     > yes
2026-06-04 04:30:35 <xentrac     > but I think RV32I errs too far in the other direction
2026-06-04 04:30:35 <tabemann    > the only instructions I have really found wanting are PUSH and POP
2026-06-04 04:30:52 <xentrac     > well, you can implement those for common cases as millicode
2026-06-04 04:31:28 <tabemann    > millicode?
2026-06-04 04:32:07 <xentrac     > yeah, subroutines you call that do microcode-like things such as saving or restoring a few registers from the stack
2026-06-04 04:32:39 <xentrac     > RISC-V suggests using a separate link register for calling them specifically so that they can store the normal link register
2026-06-04 04:32:45 <xentrac     > (or return to it)
2026-06-04 04:32:59 <tabemann    > ah gotcha
2026-06-04 04:34:19 <xentrac     > annoying things about RISC-V include the way they threw the operand fields in a blender.  probably justified by the ability to make small RISC-V implementations very small and fast indeed, but annoying as hell when you're trying to read machine code
2026-06-04 04:34:22 <tabemann    > well, there's one other thing I kinda wish RISC-V had (even though I can live without it): something akin to ARM Cortex-M's LDR R0, [R1, R2]
2026-06-04 04:35:41 <xentrac     > putting division in the M extension sucks
2026-06-04 04:36:00 <xentrac     > you can kind of look at the catalog of popular extensions to see what other people thought were annoyingly missing
2026-06-04 04:36:29 <tabemann    > I've heard the mistake the RISC-V people hade was to put multiplication and division in the *same* extension
2026-06-04 04:36:36 <xentrac     > yes, that's what I mean
2026-06-04 04:36:42 <tabemann    > *made
2026-06-04 04:36:55 <xentrac     > the M extension is the usual multiplication extension, part of RV32G and RV64G
2026-06-04 04:37:03 <xentrac     > Zmmul is multiplication without division
2026-06-04 04:37:17 <tabemann    > hardware multiplication is essential... hardware division, not so much
2026-06-04 04:38:50 <xentrac     > exactly.  I mean not *essential* but a big boost
2026-06-04 04:39:02 <xentrac     > oh hey, there's a new version of the unprivileged ISA: https://docs.riscv.org/reference/isa/_attachments/riscv-unprivileged.pdf
2026-06-04 04:40:52 <xentrac     > Zba is the thing I miss most: https://docs.riscv.org/reference/isa/_attachments/riscv-unprivileged.pdf#page=242
2026-06-04 04:41:22 <xentrac     > things like sh2add rd, rs1, rs2: Shift left by 2 and add
2026-06-04 04:42:27 <tabemann    > they have dedicated instructions for that sort of thing?
2026-06-04 04:42:53 <xentrac     > yes, because indexing into arrays is a thing you commonly do in inner loops
2026-06-04 04:42:55 <xentrac     > Zbb also has some things that are kind of like multiply in that implementing them in software can be pretty slow, but things like CLZ aren't in the inner loops of nearly as many important algorithms as multiplication
2026-06-04 04:43:02 <xentrac     > or array indexing
2026-06-04 04:45:07 <tabemann    > what about plain old multiply-accumulate?
2026-06-04 04:59:08 <xentrac     > multiply-accumulate is pretty advantageous if you can do it in one cycle, but that tends to be pretty demanding on the microarchitecture
2026-06-04 05:00:10 <xentrac     > the multiplier isn't a problem, but if you want to do a series of one-cycle multiply-accumulates with the sources and destinations in registers, you need to be able to read three registers per cycle, which usually means that your register bits need to have three read ports, which makes them kind of huge
2026-06-04 05:00:51 <tabemann    > yeah
2026-06-04 05:01:49 <xentrac     > there are alternatives, like clocking the register file at double speed or making two copies of it, but none of them are cheap
2026-06-04 05:03:35 <xentrac     > in a Forth-like stack processor you can avoid this (MAC/FMA can just read the top three stack items) but then you generally can't get to one multiply per cycle
2026-06-04 10:22:37 <veltas      > The main reason we don't use RAM as registers is performance, if we could just use RAM like registers without performance impact then registers would be pointless (assuming RAM doesn't need bootstrapping)
2026-06-04 10:22:51 <veltas      > And then e.g. forths would be easier to implement efficiently
2026-06-04 10:23:22 <veltas      > A long time ago the CPU wasn't going to run much faster than the memory bus so you could do this without a huge penalty
2026-06-04 10:25:03 <veltas      > Now we've got pipelines of renamed registers and cache hierarchy
2026-06-04 10:25:43 <veltas      > At least with L1 we've got something a little like the 6502's zero page for free if you use a small amount of memory
2026-06-04 10:53:43 <veltas      > I am designing this old win32 resource style way of specifying GUI's, I think the plan is to send like a binary description of an interface over network
2026-06-04 10:53:52 <veltas      > Sort of like a "what if HTML never happened"
2026-06-04 11:55:29 <MrMobius    > xentrac: eight registers per bank with four banks so you can quickly switch to a new bank in an interrupt
2026-06-04 11:57:00 <MrMobius    > which leaves which leaves 224 bytes for stack. some models let you put 2K in external memory for the stack
2026-06-04 12:04:51 <MrMobius    > and all 8051s have mul and div :P
2026-06-04 12:05:17 <veltas      > The 8051 seems really cool
2026-06-04 12:18:53 <veltas      > Yeah I wouldn't call hardware mul 'essential' either, but working with some legacy embedded code that relies more on shifting to avoid multiplication is a bit of a pain
2026-06-04 12:19:44 <veltas      > The biggest problem is other programmers
2026-06-04 12:19:55 <veltas      > Who do crazy things when working around it and make it harder than it was already
2026-06-04 12:20:15 <veltas      > They need easy operators that they can use
2026-06-04 13:55:36 <veltas      > This is a seriously underrated style: http://www.catb.org/esr/writings/taoup/html/ch09s01.html
2026-06-04 13:58:23 <veltas      > Data-Driven Programming
2026-06-04 14:19:45 <veltas      > The examples aren't even that good there