9

This question occurred to me while I was formulating this answer about arithmetic versus logical shifts.

The IBM 709, and its descendant the 7090, etc., is a 36-bit mainframe with a classical single-accumulator architecture, word-addressed memory, and so on.

Unusually (or so it seems to me), the accumulator is slightly wider than the word size: it is 38 bits rather than 36 bits.

Where a memory word is considered to have a sign bit S and 35 magnitude bits (1-35, with 1 being the MSB), the accumulator has sign bit S, and bits Q, P, and 1-35, with Q and P being "to the left of" bit 1. Incidentally, this nomenclature shows the downside of adopting big-endian bit numbering.

The extra bits provide the benefit of explicitly retaining information that overflows from addition and subtraction operations. Neither bit P nor Q is "the" overflow indicator; the overflow is set as bits pass in or through P -- the temptation to look at this as just a odd way to regard condition codes does not seem to me to work out.

However, the extra two bits in the "middle" of the accumulator means that the instruction set distinguishes loading the AC with an arithmetic value from loading AC with a logical (unsigned) value. The former copies the memory word into S and 1-35, clearing P and Q. The latter copies it into P and 1-35, clearing S and Q.

Anyway, to get round to the question: apart from the 709 and its 7-series offspring, were there other systems that had registers "slightly larger" than memory words? Any non-IBM systems?

Here I use "registers" in the modern sense, as being logically a part of the CPU, and distinct from memory.

I want to exclude computers that support multiple operand lengths -- e.g., a 32-bit machine with 32-bit registers that also has 16-bit arithmetic, and computers with double-length registers for supporting (for example) full-word multiply with a double-length result.

It's the "couple of extra bits" aspect that intrigues me.

Addendum:

This paper on the design of the IBM 701 discusses the decisions leading to extending the accumulator by two bits (see p 1270).

dave
  • 35,301
  • 3
  • 80
  • 160
  • Do the extra bits need to extend data in a regular way, like the P and Q bit (but unlike the S bit)? If not, I guess there's a few example where registers get "tag" bits with additional functionality. E.g. in the Mill, in some Lisp machines, and maybe even in some Burroughs machine (though I'd need to look that up). And there's the reverse case, where you have registers intended for addressing that are smaller than the acc. register size, and loose bits when transferring from acc or memory. – dirkt Feb 26 '21 at 06:54
  • I'd consider tag bits on a case-by-case basis, I had not thought of that. For address-holding registers, I'd say 'not', they're just a consequence of address size being less than word size. – dave Feb 26 '21 at 12:39
  • 1
    @dirkt - don't know about the Mill but in the Lisp Machines (LMI, Symbolics) the tags were stored in memory so "registers" (such as they were, for the microcode, not usually for the user) were the same length as memory in that case. AFAIK. – davidbak Feb 27 '21 at 19:13
  • For the record, the IBM 704 had an extra bit in its accumulator and technically isn't a descendant of the 709 (but I'm sure that's not an answer you're looking for). – texdr.aft Mar 01 '21 at 22:46
  • 3
    The 704 doesn't count, it's not a computer, it's an "electronic data-processing machine", at least that's what it says on the manual :-). But yes, the 704 has the same P and Q bits in the ACC. Thanks. Not sure how I missed that in my question. The 701 also has P and Q, so it looks like an established feature of the 7-series machines. – dave Mar 02 '21 at 00:37
  • 1
    The 701 led me to an interesting paper - see my latest edit. – dave Mar 02 '21 at 01:27
  • 3
    Not so "retro", but Itanium has an extra "Not a Thing" bit for each register: https://devblogs.microsoft.com/oldnewthing/20040119-00/?p=41003 – Nate Eldredge Oct 04 '21 at 00:05
  • 1
    @another-dave, Ha Ha! Yes! And the Hewlett Packard 98xx series desktop machines weren't computers either because a Physics department could purchase a $3000 or $5000 "calculator" and not have to answer to anybody, but to purchase a $3000 or $5000 "computer" would require approval by boards and committees and who knows what other organs of bureaucracy. – Solomon Slow Oct 06 '21 at 21:59
  • 2
    P.S., Speaking of calculators,... Maybe not quite the same thing, but back in the day, some scientific calculators calculated one or two more digits (so-called "guard digits") than what they showed on the display. – Solomon Slow Oct 06 '21 at 22:05
  • 1
    @SolomonSlow they still do that nowadays. Casio scientific calculators only show 10 digits but internnally I guess they use IEEE-754 double precision – phuclv Oct 09 '21 at 11:30
  • 1
    @phuclv, Anything that you build today, if it needs floating point, you're going to use IEEE (unless you need even more precision.) Hardware FPUs are inexpensive and ubiquitous. It would be foolish not to do. But the calculators I was thinking of pre-dated the IEEE standard, they didn't have FPUs, they had only hundreds (or even just tens) of bytes of RAM in which to store results. When the engineers who designed those machines allocated space for hidden digits and, wrote the code to compute them, that was a deliberate choice that added real cost to the design. – Solomon Slow Oct 09 '21 at 15:11

6 Answers6

12

Intel Itanium, aka IA-64, has 82-bit floating point registers. These are intended to preserve accuracy in intermediate values, but storing them into memory without losing that accuracy is expensive: they occupy 16 bytes of RAM.

The x87 floating-point registers on ordinary x86 CPUs can handle 80-bit values, but those were intended for use with 80-bit variables, rather than providing 16 extra bits for regular 64-bit variables, which is unnecessarily generous. The Itanium's 82-bit registers were intended to provide better accuracy on 80-bit variables.

The Motorola 68881 floating-point co-processor for the Motorola 68020 and 68030 CPUs had 80-bit extended precision for the same reasons as the x87. Some programmers thought of this as "triple precision" because it was stored in memory as 96 bits for alignment reasons, but that isn't correct.

Brian Tompsett - 汤莱恩
  • 5,597
  • 1
  • 23
  • 39
John Dallman
  • 13,177
  • 3
  • 46
  • 58
  • 6
    You might even count the 8087, since its registers stored 80-bit extended precision but the intention was that code should normally load and store them as 64 or 32 bits. (Of course you can load/store 80 bits if you want, but the machine doesn't make it too convenient to actually work with those objects.) – Nate Eldredge Oct 07 '21 at 05:57
  • @OmarL: I miss-remembered some details, how's this? – John Dallman Oct 08 '21 at 09:35
  • That's all good – Omar and Lorraine Oct 08 '21 at 11:29
  • 2
    @NateEldredge: It's funny that 80-bit types are so strongly associated with the 8087, when they had just as much value on CPUs that didn't have floating-point units. Performing any computation ondouble` without an FPU on a 16-bit or 32-bit processor requires splitting it into an exponent that must be more than 8 bits and may as well be 16, mantissa that must be more than 48 bits and may as well be 64. While the extended-precision types were bigger, computations on them could be faster, especially if an implementation kept track of two subtypes: those that were known to be... – supercat Oct 08 '21 at 15:40
  • 1
    ...potentially non-normalized, and those that weren't (any object that was known to be potentially non-normalized would need to be normalized before it was compared, multiplied, divided, or stored to memory). If a program computes a=b-c+dwhenb,c, anddhave similar magnitudes, keepingb-cin non-normalized form would avoid the need to shift it to align it withd`. – supercat Oct 08 '21 at 15:45
  • @supercat: Have 80-bit or larger types been used much for software floating-point? I've seen MBF (32, 40 or 64 bits) and IEEE 32- and 64-bit done in software. Borland's 48-bit real format was popular for a while, and I see they had 80-bit in software. – John Dallman Oct 08 '21 at 17:08
  • @JohnDallman: The Standard Apple Numerical Environment supported by "classic" Mac OS supported 32, 64, and 80-bit floating point types, and the documentation stated that on machines without an FPU, double would be the slowest type. I don't know to what extent compilers for the Macintosh or any other platform kept intermediate results in 80-bit floating-point types between computations, but those that didn't could have offered better performance if they had. – supercat Oct 08 '21 at 17:15
  • @JohnDallman: BTW, I think Turbo C 2.1 uses 80-bit floating-point types with or without an FPU, but I don't know how to disable the FPU in a virtual machine to ascertain that for certain. – supercat Oct 08 '21 at 22:08
  • @JohnDallman they're common in applications when IEEE binary64 isn't enough but quaduple precision is too slow. See Did any compiler fully use Intel x87 80-bit floating point? – phuclv Oct 09 '21 at 11:25
  • 1
    "The x87 floating-point registers [...] were intended for use with 80-bit variables, rather than providing 16 extra bits for regular 64-bit variables" - I'm pretty sure that's not true. They were intended to make it easier to calculate a 64-bit value as a complicated function of other 64-bit values without needing to think too hard about cumulative roundoff of intermediate results. At least, that's what William Kahan said. – benrg Jun 09 '23 at 05:50
8

After all this time, perhaps I should attempt to answer my own question.

It appears to have been a feature of the IBM 700-series of scientific machines, as described in Buchholz's paper, and of course was replicated in their transistorized descendents, the 70xx.

I haven't found any similar approach, so until contradicted here (which I actively invite), I'll assert it was a unique design.

dave
  • 35,301
  • 3
  • 80
  • 160
6

It is common for digital signal processors to have an accumulator which is wider than the memory bus, but may not necessarily be twice as wide. Although the only DSP I used had a 16-bit memory bus and a 32-bit accumulator that was twice as wide, I believe 40-bit accumulators are fairly common. It's common in a DSP to add together the products of many pairs of 16-bit values, which would overflow a 32-bit accumulator. While the part I used got around that problem by having an option to shift the results of multiplications right by 6 bits before the addition, allowing groups of up to 128 products to be added without overflow, my understanding is that other vendors' parts instead use a 40-bit accumulator so as to allow groups of up to 512 numbers to be added while keeping results in full precision.

supercat
  • 35,993
  • 3
  • 63
  • 159
5

The Apollo Guidance Computer had some 16 bit registers while the memory word size was 15 bit. The accumulator used this extra bit for overflow detection. See here for a detailed description.

WimC
  • 1,086
  • 7
  • 9
2

The PDP-8's link bit is effectively the 13th bit in the accumulator. In practice it works as a carry bit, the shift-in bit for rotations, and a general purpose flag.

RETRAC
  • 13,656
  • 3
  • 42
  • 65
  • Hmm, interesting. I'll look into that. – dave Feb 26 '21 at 16:48
  • 1
    I'd disagree, the link bit in the PDP-8 is not different from, say, the carry bit in the 6502 status register, or probably the carry bit in most CPU architectures. In the IBM 709, the P bit can be loaded from and stored to memory directly, as part of the accumulator register. That's the important difference. – dirkt Feb 27 '21 at 09:17
  • 6
    The Link bit is different from a carry bit. If an addition overflows, the Link bit is complemented, but a carry bit is set in that scenario – Omar and Lorraine Feb 28 '21 at 08:29
2

As already mentioned, a larger accumulator register is quite common in DSPs. Most 32-bit DSPs have 40-bit accumulators and 64-bit DSPs have 80-bit accumulators. Another example is the TI TAS3xxx audio SoC which is a 48-bit DSP series (TAS3202, TAS3204) with

  • 76-bit ACC (accumulator) register
  • 28-bit MC coefficient register
  • 32-bit DO1-DO8 registers
  • 2-bit LFS register
  • 48-bit data registers (most of the remaining registers)
phuclv
  • 3,592
  • 1
  • 19
  • 30