Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on March 22, 2021 6:10 am wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on March 22, 2021 4:24 am wrote:
> > Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on March 22, 2021 3:22 am wrote:
> > > ...
> > > On a more complete redesign of a processor, I would easily "type" the registers of the processor (as I have
> > > said in old threads), i.e. have assembly instructions to change the type of each registers at run time.
> > > I imagine processor registers could have types like:
> > > - simple byte/word/long or any fixed number of bits like all processors
> > > - pointer to memory (probably 64 bits), maybe with read-only/write-only/read-write
> > > distinction (would help cache prefetch for read or write at value initialisation)
> > > - Integer/unsigned which would saturate on overflows, or bitmasks types
> > > - floating point of fixed number of bits
> > > - vector of byte/word/long/floats...
> > > At least it would reduce the number of instructions (addb, addw, addl, ...), clearly define when a register
> > > is live or dead, and give more context to the core executor. At first one could fix all registers being
> > > 64 bits to use standard current compilers, and implement other types slowly, one at a time.
> >
> > Well I know of one ISA that did a simple form of that - the length of the operation was set by the
> > load and then operations like add worked at that length. The operations were mostly register-memory
> > so savig a bit mattered but you wouldn't save much with risc except for a compressed version.
> >
>
> Adding 1 to a byte involves a mask with 0xFF on RISC (most of the time).
> Adding 1 to a vector of 4 bytes inside a register is not the same a adding 0x01010101 to a 32 bits register.
> I see quite a few possible improvements by giving more to do to the "core executor"
> (i.e. mostly ALU) in each cycles, even if that slows down slightly the cycle time.
> And having a more orthogonal instructions set is not a bad thing.
> The advantage of this very big change (typing registers) would be that one can
> fix their type at boot for first introduction/tests, and proceed one per one
> each type (getting prefetch right when an address register is initialised)

The only real problem I can see with the idea is saving and restoring registers in a procedure entry and exit. The one I was talking about was basically stack based and didn't do that and the length was stored in the program status word. In a straightforward implementation one would have to allocate the largest size and more nd have a special load and store instructions for them. Or somthing like SPARC's register banks.

The amount that may need to be saved switching from one process to another is growing and calling procedure is a smaller but more frequent version of that. And it would be nice if the values are never even stored away if the original environment is restored quickly. If this problem could be solved in a really nice way then the problem of the extra space for tagged registers might to a large extent disappear.