Re: Computer architects leaving Intel...

EricP wrote:

These double-width bit-field straddle operations show up at 32-bits.
Various FP64 formats (DEC's middle-endian FP being the worst example),
Intel page table entries and segment/gate descriptors, come to mind.

Lots of them in 32-bit code!

 It's just going to take a while for double-width things to show up
at the 64-bit level. But if FP128 becomes a reality...

If???

Codecs likely have to deal with double-width straddles a lot, whatever
the register word size. So for them it likely happens at 64-bits already.

Nothing likely about it: LZ4 is pretty much the only compression algorithm/lossless codec that never straddles, all the rest tend to treat the source data as single bitstream of arbitrary length, except for some built-in chunking mechanism which simplifies faster scanning.
The core of the algorithm always starts with knowing the endianness, then picking up 32 or 64-bit chunks of input data (byte-flipping if needed) and then extractin the next N bits either from the top of bottom of the buffer register.
AlLmost by definition, this is not code that a compiler is setup to help you get correct.

 I added a bunch of instructions for dealing with double-width operations.
The main ISA design decision is whether to have register pair specifiers,
R0, R2, R4,... or two separate {r_high,r_low} registers.
In either case the main uArch issue is that now instructions have an extra
source register and two dest registers, which has a number of consequences.
But once you bite the bullet on that it simplifies a lot of things,
like how to deal with carry or overflow without flags,
full width multiplies, divide producing both quotient and remainder.

Very nice!
This means that you can do integer IMAC(), right?
(hi, lo) = imac(a, b, c); // == a*b+c
The only thing even nicer from the perspective of writing arbitrary precision library code would be IMAA, i.e. a*b+c+d since that is the largest combination which is guaranteed to never overflow the double register target field.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"