Scarcely innovative. 64 bit architectures predated the 64-bit x86 by decades. Call it a natural evolution.

Where?

The CPU Price it keeps going UP ... :( 8008 $25 1975 8080 $75 MITS kit 1975 8088 $125 386  $130 (286 $20)

On 10/06/2024 00:28, ben via cctalk wrote: Hardly, you can pick up a new CPU today for less than $50. It's not going to be particularly fast, but it'll run circles round most decade old CPUs.

I think the biggest change (other than speed, word length etc), is number of SKUs. For desktop systems, there are dozens of different SKUs per microarchitecture, each with varying cache size, core count, clockspeed, and present/absent integrated graphics. In the server space, the varying SKUs are amplified, with number of PCIe lanes, socket support etc almost multiplying the number of SKUs by an order of magnitude. Josh Rice

On 2024-06-09 11:01 a.m., Chuck Guzis via cctalk wrote: still More reliable. Can you trust a CLOUD? How soon will your data be corrupted, or behind a paywall?

Highly parallel workloads are an important niche in computing. On Mon, 10 June 2024, 8:48 am Scott Baker via cctalk, < cctalk(a)classiccmp.org&gt; wrote: actually are

On Jun 10, 2024, at 12:18 PM, Joshua Rice via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On 10/06/2024 05:54, dwight via cctalk wrote: Pipelining has always been a double edged sword. Splitting the instruction cycle into smaller, faster chunks that can run simultaneously is a great idea, but if the actual instruction execution speed gets longer, failed branch predictions and subsequent pipeline flushes can truly bog down the real-life IPS. This is ultimately what led the NetBurst architecture to be the dead-end it became.

DEC came across another issue with the PDP-11 vs the VAX. Although the pipelined architecture of the VAX was much faster than the PDP-11, the actual time for a single instruction cycle was much increased, which led to customers requiring real-time operation to stick with the PDP-11, as it was much quicker in those operations. This, along with it's large software back-catalog and established platform led to the PDP-11 outliving it's successor. Josh Rice

On Jun 11, 2024, at 11:52 PM, ben via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On 2024-06-10 10:18 a.m., Joshua Rice via cctalk wrote: The other gotya with pipelining, is you have to have equal size chunks. A 16 word register file seems to be right size for a 16 bit alu. 64 words for words for 32 bit alu. 256 words for 64 bit alu, as a guess.

You never see a gate level delays on a spec sheet. Our pipeline is X delays + N delays for a latch.

On Jun 13, 2024, at 2:00 PM, Chuck Guzis via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On 6/13/24 10:32, Paul Koning via cctalk wrote: Indeed. There are architectures with NO user-addressable registers. Some have memory-mapped registers, where a "register number" is merely shorthand for a memory address (i.e. implicit multiplier and base) --Chuck

Gate level delays are not interesting for the machine user to know. What is interesting is the detailed properties of the pipelines, including whether they can accept a new operation every cycle or just every N cycles (say, a multiplier that accepts operands every 2 cycles); how many cycles is the delay from input to output; and whether there are "bypass" data paths to reduce the delays from input or output conflicts. Often these details are hard to pry out of the manufacturer; often they are not documented in the standard data sheets or processor user manuals. But they are critical if you want to do work such as pipeline models to drive compiler optimizers.

paul

You compare machines by what they deliver. The purpose of computers is not to deliver logic circuits but to deliver computation, so comparing computational ability (speed and size) is meaningful, along with cost. How it's implemented under the covers is not. Yes, the implementation details affect the user's figures of merit, but those figures and not the logic choices made by the designers matter.

Fun factoid: despite modern x86 being clocked ~1000x faster than ye olde 6502, there's not much in it between them when it comes to interrupt response time. If all goes well, x86 takes "only" a hundred-ish cycles to do its book-keeping and jump to the ISR, but if SMM is active (spoiler: it always is and you can't turn it off) then it introduces a massive amount of extra jitter and all bets are off.

On 6/12/24 03:02, Peter Corlett via cctalk wrote: Well, actually the Pentium classic was supposedly designed as the flight computer for the F-15, and had VERY good interrupt response time of around 5 us.  We know all about this as we used it with real time Linux in CNC motion control systems.  A big concern was what was the delay and jitter from the RTC triggering an interrupt to when the servo position counters were read.  It has been a struggle to maintain this level of low jitter with newer processors, but we have found quite a few that can do it.

Even without things like system management mode, there are lots of speed-up features on modern processors that result in variable execution times - things like caching and pipelining. With sufficient care these can sometimes be made predictable but there are certain common needs that have always found it better to have a dedicated peripheral to do these jobs. The first common one was possibly the Motorola TPU (time processing unit) on the 68332 and others. The target application was injection timing for automotive ECUs and although external dedicated logic such as FPGAs have also been used, the microprogrammable peripheral has continued to be a feature of some relatively common processors. The TI processor in the beaglebone has PRIs, the raspberry pi Pico RP2040 has PIOs, and there's also the parallax propellor which has 8 high speed parallel processors running at 80MHz and able to interleave operations on common ports : a newer version has iirc a 1Ghz clock. Another technique has 'abused' dma and serial data peripherals on esp8266, esp32 and Teensy processors to produce pulse trains for WS2812 LED control at IIS clock rates. They construct the desired output waveform in memory and DMA them out, though this may be unsuitable for servo control as the buffers are large, giving good precision but poor latency. On Thu, Jun 13, 2024 at 4:40 PM Jon Elson via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: > On 6/12/24 09:52, Jon Elson via cctalk wrote: >> On 6/12/24 03:02, Peter Corlett via cctalk wrote: >>> Fun factoid: despite modern x86 being clocked ~1000x >>> faster than ye olde >>> 6502, there's not much in it between them when it comes >>> to interrupt >>> response time. If all goes well, x86 takes "only" a >>> hundred-ish cycles to do >>> its book-keeping and jump to the ISR, but if SMM is >>> active (spoiler: it >>> always is and you can't turn it off) then it introduces a >>> massive amount of >>> extra jitter and all bets are off. >>> >> Well, actually the Pentium classic was supposedly designed >> as the flight computer for the F-15, and had VERY good >> interrupt response time of around 5 us. We know all about >> this as we used it with real time Linux in CNC motion >> control systems. A big concern was what was the delay and >> jitter from the RTC triggering an interrupt to when the >> servo position counters were read. It has been a struggle >> to maintain this level of low jitter with newer >> processors, but we have found quite a few that can do it. > AACK! Sorry, that was supposed to be F-16! > > Jon > >

I think I recall an early processor that did out of order execution, without checking, meaning you could have add xxx to accumulator store accumulator in zzz and the store could happen before the add if there weren't sufficient instructions between the two. I *DON'T* recall if it was designed this way or a defect in the chip design. I think it was intended to be a real-time process control cpu and speed was more important than ease of programming. There was a assembler/compiler that warned of this case, afaik

The architecture designers cheated however even in the original ISA in that moves from the MD accumulator did interlock.  I guess they figured people (either doing it by hand or by writing a compiler) wouldn't get that right anyway. ;)

The MIPS R4000 manual https://groups.csail.mit.edu/cag/raw/documents/R4400_Uman_book_Ed2.pdf says that double precision divide is 36 cycles, and double precision square root is 112 (!).

What's interesting about that is that GCC's model of the R4000 says that divide is 69 cycles; I'm not sure of the reason for the discrepancy. https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/mips/4000.md;h…

On Jun 13, 2024, at 6:22 PM, Jonathan Stone via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: On Thursday, June 13, 2024 at 03:00:22 PM PDT, Maciej W. Rozycki via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: I always assumed that was because the latency of multiply, let alone divide, was far too many cycles for anyone to plausibly schedule "useful" instructions into. Wasn't r4000 divide latency over 60 cycles? Wasn't r4000 divide latency more than 60 cycles?

I may be wrong, but wasn't that a feature of early RISC, possibly the Sparc ? You were compiling to microcode rather than CISC assembler, so you got to think about pipelining in the instruction stream. Just about feasible in assembler but perfectly sensible if the compiler was doing the work.

On Jun 15, 2024, at 1:41 PM, Chuck Guzis via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: I'm certain that Paul has done his share of this, but an art on the CDC 6600 was hand-scheduling instruction execution. There was at least one class for this--and probably more. The CPU could issue one instruction every cycle, assuming that there were no conflicts. The 6600 had several functional units whose operation could overlap.

On Jun 13, 2024, at 12:15 PM, CAREY SCHUG via cctalk &lt;cctalk(a)classiccmp.org&gt; wrote: I think I recall an early processor that did out of order execution, without checking, meaning you could have add xxx to accumulator store accumulator in zzz and the store could happen before the add if there weren't sufficient instructions between the two. I *DON'T* recall if it was designed this way or a defect in the chip design. I think it was intended to be a real-time process control cpu and speed was more important than ease of programming. There was a assembler/compiler that warned of this case, afaik

MIPS, perhaps? It has "delay slots".

A pipelined FP operation immediately followed by a store will not store the result of that operation. Needless to say, programming in pipelined FP mode is challenging, but it's the way to get the highest FP performance out of the i960. Math libraries used hand-written code to do that, but I don't think any of the i960 compilers were smart enough to do it for you.