Sujet : Re: Why I've Dropped In
De : quadibloc (at) *nospam* gmail.com (quadibloc)
Groupes : comp.archDate : 11. Jun 2025, 20:37:03
Autres entêtes
Organisation : novaBBS
Message-ID : <3631df2ad220d4ab6df0cd44e7f38f4e@www.novabbs.com>
References : 1 2 3 4 5 6 7
User-Agent : Rocksolid Light
On Wed, 11 Jun 2025 18:56:56 +0000, EricP wrote:
The problem is that there are 7 integer data types,
signed and unsigned (zero extended) 1, 2, 4 and 8 bytes,
and potentially 5 float, fp8, fp16, fp32, fp64, fp128.
There might also be special (non-ieee) float formats for AI support.
Plus one might also want some register pair operations
(eg load a complex fp32 value into a pair of fp registers,
store a pair of integer registers as a single (atomic) int128).
Even I have refused to contend with all of this, at least for my basic
32-bit instruction set. Some exotic types that I do intend to support
will just have to make do with 48-bit or longer instructions instead.
But signed and unsigned integers aren't _quite_ the same as different
types for load and store. I may have separate integer and floating
registers, but I don't have separate signed and unsigned registers.
Instead, I've followed the System/360. When it comes to load and store,
for integers I have two additional operations - unsigned load and
insert. But only for integers shorter than the register.
Load sign extends. Unsigned Load zero extends. Insert leaves bits in the
register preceding what is loaded untouched.
Since arithmetic is two's complement, there is only one add instruction,
and there is only one store instruction, for each length. If we were
really dealing with different types, we would need additional
instructions of those kinds as well.
For floats, I deal with fp32, fp48, fp64, and fp128 only as the primary
floating-point types.
John Savard