@MSGID: 1@dont-email.me> 9753ab8a
@REPLY: 1@gal.iecc.com> 5cb72425
@REPLYADDR Terje Mathisen
<terje.mathisen@tmsw.no>
@REPLYTO 2:5075/128 Terje Mathisen
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References:
<57c5e077-ac71-486c-8afa-edd6802cf6b1n@googlegroups.com> <c35d6ff9-420e-438f-ac5c-78806df57f91n@googlegroups.com>
<71d6df28-ece0-4aa4-b07c-051ca81aab4an@googlegroups.com> <000949fe-1639-41b3-ae9e-764cdf6c9b4bn@googlegroups.com>
1@gal.iecc.com>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.17
@TID: FIDOGATE-5.12-ge4e8b94
John Levine wrote:
> According to Quadibloc  <jsavard@ecn.ab.ca>:
>> I have an idea, from what I`ve read, about what lengths are desirable
>> for floating-point numbers.
>>
>> Integers... well, the primary integer type needs to be big enough to
>> serve as an index to an array. 32 bits used to do that, and now we need
>> 64 bits. Although the physical memory addresses are really only 48
>> bits... but then, if bigger arrays can live in virtual memory, then indexes
>> into them will also be wanted.
> 
> The 801 decided that it need registers big enough to hold addresses,
> which in that era were 24 bits. I don`t see anything`s changed there
> except that addresses are bigger.
> 
>> On the System/360, of course, packed decimal integers were like
>> *strings*, and could be any length. But those operations were
>> memory to memory, and thus they would be very slow on today`s
>> computers. So the ability to do packed decimal operations in
>> registers is important.
> 
> They considered and rejected decimal registers because in that era,
> decimal calculations tended to be simple and I/O limited so there
> weren`t enough intermediate values to make registers worth it.
> 
> But on z/Series they do indeed have packed decimal vector instructions
> using the 128 bit vector registers as 31 digits and a sign. There is

So really nybble math?

I find it interesting that Intel included a set Ascii/Nybble 
instructions on the 8086/88, this might have  been the least used part 
of the entire x86 instruction set?

There are some exceptions, typically related to size optimization 
contests where these single and double-byte opcodes were abused because 
they were shorter than the normal way to do stuff, like splitting a byte 
into hex nybbles by using the initially undocumented feature of using 16 
to do div/mod 16 instead of mask and shift.

Even on the original 8086 you could pack 4 nybbles into a register and 
operate on them in parallel, and as soon as we got to the 386, packing 8 
nybbles into a 32-bit reg was so much faster than any nybble-based loop 
was just stupid.

Terje

-- 
- 
"almost all programming can be viewed as an exercise in caching"
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 SeaMonkey/2.53.17
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441