Hacker News Reader

The amount of silicon legacy code takes up literally decreases non-linearly with each process shrink.

The amount of baggage x86 is carrying around now days long ago shrunk to the point of not mattering.

And sure, if some ancient compiler spits out some opcode that Intel long ago stopped optimizing, it may take 10x the clock cycles it used to take back in the days of 386s, it is still going to run 100x faster at the end of the day.

> We don't yet consider ARM CISC, right?

I think ARM64 was an attempt to prevent that from happening! I haven't looked into it at all so I am not sure how successful they were. But it was starting to get pretty close there for awhile.

Actually it was in contrast to the Vax instruction set ... the PDP instruction set is something else (and some Vax's had a PDP emulation mode ....)

VAX was a crazy town ISA too, with stuff like single isntruction polynomial evaluation.

Crazy for its age, but all modern processors (x86, ARM, and Power9) implement a polynomial multiplication.

ARM: vmull.p8

Intel: PCLMULQDQ

Power9: I forget, but trust me, its in there somewhere.

IIRC, they're all 64-bit carryless (or polynomial) multiplications. The funniest part is that ARM and Power9 still claim to be "reduced instruction set computers", despite having highly specialized instructions like these. Power9 is the funniest: implementing hardware-level decimal-floats (for those bankers running COBOL), quad-floats (for the scientific community), Polynomial-Multiplication and more.

Not GF polynomial multiplication, full Horner's method polynomial eval in a single instruction.

https://web.archive.org/web/20181126134850/http://uranium.va...

Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length".

Here's a CRC32 impl using POWER8/9 polynomial instructions: https://github.com/antonblanchard/crc32-vpmsum — coincidentally, you don't have to do this on ARM, ARM just has CRC32 instructions.

> hardware-level decimal-floats (for those bankers running COBOL)

IBM being IBM :) I've heard somewhere that they are sharing some internals between POWER and z/Architecture (mainframe) chips. No idea how true it is and how much is shared if true, but a scenario like "decimal floats were implemented because mainframes are using the same backend with a different frontend, so we exposed them in the POWER frontend too" sounds quite plausible.

Well, the meaning of "reduced" has shifted from "not having specialized instructions" to "load-store and preferably fixed-length".

Ain't that the truth. Reduced never meant anything; they never defined it. Patterson said they cooked up the name on the way to a grant presentation. I think they should call it Warmed Over Cray. What was new in RISC that wasn't in Cray? It was like the Geometry Engine; it was possible for an academic department to accomplish but that doesn't mean they accomplished anything that hadn't already been done.

preferably fixed-length

Or fixed-length/2.

IBM likes decimal floats because of COBOL (and maybe RPG?).

To be fair, even back in the day decimal arthimetic could at least have an argument made for it on RISC chips. https://yarchive.net/comp/bcd_instructions.html

Which resulted in a particular problem .... worst case an instruction could cause 21 different page faults (because of all the operands), that meant that every process had to be able to have an in-core working set of a minimum of 21 (512-byte) pages in order to make progress, at a time when memory was not cheap and plentiful

more importantly too many operands with side effects (auto increments) result in complexity in the handling of exceptions (do you restart or save partial internal state - compare the 68020 with the 68040 for example)

Yep. I'm playing with a 68k decoder frontend for a modified boom core. Indirect memory accesses are the bane of my existence at the moment.

- 68000s were just broken (couldn't restart a page fault) - we still put unix on it, hacked the compiler to probe the stack to do stack extension on swapping only systems

- 68010s were essentially a 68000 with this fixed - unix could do a real paging system

- 68020s dumped their entire microcode state on the kernel stack - to do signals correctly (ie recusively) unix systems had to be able to spill this to user space and validate it on the way back in

- 68030s and 68040s were saner and restarted exceptions in useful ways

Wow. Having pretty much ventured from 6502 directly to the 386 and later ARM, 68k was something I never really took a close look at. Was that limitation in the original 68000 unintentional, or did they just not design for faulting in virtual memory at page granularity?

After all, you don't need to be able to restart on a page fault if you just swap in whole tasks out and back into memory just before switching to them (which you know when you're going to do), and you still get virtual memory's benefit of the swapped in tasks being able to occupy different physical, and discontiguous, memory regions without the task itself noticing.

So did they only design for that, or did they actually make a mistake?

They didn't support any MMU at all. People would add one as a separate chip, right between the CPU and the RAM, but this wasn't supported. The CPU was unaware of it. There was no way for the MMU to tell the CPU to take a recoverable fault.

Sun solved this problem in an expensive way. The MMU would make the CPU wait while a second 68000 was used to process the page fault.

Ah, your comment about them being "broken" led me to believe that some form of virtual memory was expected in the design.

Now that you mention it, I recall reading that two 68000s story before (possibly from another comment you made here?), and reading it this second time, it still amazes me. Is it possible to find the source code involved? Not sure what of Sun's kernels is available.

There was no builtin in MMU in early chips (68000-68020). An external MMU for the 68000/68010 did exist - a weird thing called a 68451 that mapped arbitrary power of two aligned physical blocks of memory to arbitrary power of two aligned virtual addresses (harder to use and particularly hard to allocate memory for) - it was VERY slow (7 clocks from memory) and was rumored to have been designed by a summer intern at Moto.

You do need to restart instructions if you want your stack to extend automatically, there's a hack you can do to make this happen on a 68000

You could do a paging system on a 68010/68451 - you had to treat the 68451 as a software refilled TLB

Sun built their own MMU using SRAM, at the time there was a guy going around the Valley designing "sun-style" MMUs, for IP reasons every one was different, some were broken (one I ported to couldn't protect the kernel from user mode).

Someone (maybe Sun?) managed to get 68000s to do paging by having two of them and freezing the primary on a page fault and having the second one load the page somehow.

68020s had external MMUs, Moto made the PMMU which most people used Phillips tried to make one (it never really worked), Apple had a weird pseudo MMU that fit in a PMMU socket on the mac 2 - it emulated the 24-bit addressing on the 68000 (Apple had stupidly used the upper bits in their pointers)

Finally: I think that the 68000 not being able to restart a page fault was probably a mistake, something they hadn't thought all the way through

I've since also found a comment on an interesting blog post in which one of the original designers is quoted in saying that virtual memory was not a consideration for the 68000 initially: http://www.dadhacker.com/blog/?p=1383

Though qualified with "until the design was almost complete", making the answer to my question (as often) much more fuzzier than I thought.

And another commenter speculates it was Apollo with the two-68k implementation, but without sources and the commenter is unsure of it themselves.

In any case, very interesting stuff.

EDIT: Someone else claims it was Masscomp: http://www.dadhacker.com/blog/?p=1383#comment-3582

That article kind of mixes up AT&T releases - we'd ported V7 and System 3 to the Lisa (base and bounds MMU like the original PDP-11 the ports came from), and the 68451 and Sun-style MMUs by mid '84, SVR (System 5 Release 1) didn't exist yet. SVR2 was a full paging release from AT&T (competing with BSD 4.2 by then).

The '451 is more functional than his power of 2 design (because it offers multiple powers of 2 that you can cobble together into arbitrary regions) - the 'throwaway instructions' he mentions is indeed what we used for stack extensions - you do a 'tstb offset(%sp)' in every subroutine entry where 'offset' is the extent of the stack the subroutine will use, the results of the instruction aren't used and the fault can be detected - by recognizing the instruction at the fault pc offset and returning to the address following it

Thanks for your insights, and for clarifying (I primarily linked to the article for its comments, which seemed to contain a collection of interesting historical tidbits.)

Again as someone who somehow never got to touch 68k during its day, the level of creativity required in 68000 MM, and the internal state spilling of the 68010 and later, really got me curious (x86 of course always had plenty of curious quirks, but I think I'm too familiar with them at this point %) ).

I'd also still love to read more about the details of the two-68000 design, but everything I could find so far was essentially folklore.

I'm afraid I never saw one, we did over 150 unix ports in the mid to late 80s and saw just about everything out there

From what I could glean from the combined 68000+68010 data sheet, the 68010 also dumps some internal state on the stack to support restarts, though that now just makes me more curious about the differences between 68010 and 68020 in that regard.

> worst case an instruction could cause 21 different page faults

Funny story is that this is still kind of a problem today, where a single pointer-dereference may be an mmap'd file over a network over SSHD tunneled through (increasingly arbitrary indirections).

foo->next = bar->next->next can be surprisingly complicated. I don't think most programmers think to handle SIGBUS errors.

Not exactly the same problem, though, since once you dereferenced one pointer, you technically don't need its page anymore. So in a truly pathological case, your bar->next->next could be "page in the page for bar, move pointer to register, throw page away, page in the page for next, move pointer to register ...".

Whereas to me, it sounds like this polynomial evaluation instruction needed all the 21 pages within one (very "large") instruction, meaning you actually need to have those (again, pathological case) 21 different pages present at once?

EDIT: A sibling comment mentioned keeping partial state of (apparently) single instructions instead of fully restarting them. So that might be an option, too.

Also do you like prefixes? Asking for a friend.

If you like x86 at all then prefixes are not a good thing but indeed a great thing. Prefixes are what allowed AMD to completely destroy Intel's Itanium. They simply took x86 and reused the REX prefix to access 16 more registers. Yeah, the committed a few other architectural atrocities before the god of expediency, but they won and Intel had to crawl back and beg forgiveness in the x86 space that they owned.

> one could design a modern CISC-y IA without all the legacy baggage of x86

You are talking about ARM here, aren't you?

But seriously, there is no reason not to say ARM is CISC. It's not the old AI it used to be anymore.

ARM is load-store and fixed-length, which seem to be the defining traits of "RISCiness" these days :)

btw, one of the "best" x86 features is the string instructions:

https://lobste.rs/s/m7ioti/risc_is_fundamentally_unscalable#...

> the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location

In thumb2 mode, an ARM will not be fixed-length: instructions may be 16 or 32 bits long.

I'm talking about aarch64, I don't care about 32-bit stuff.