Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The x86 architecture is the weirdo, part 2

devblogs.microsoft.com

Post reply on HN
Print view View original

151–160 of 170 posts

Re: The x86 architecture is the weirdo, part 2

#151

Post by notacoward »

AnimalMuppet wrote: post #120
titzer wrote: post #74

Earlier quoted context omitted.

These are all microarchitectural things that should not be surfaced in language, IMHO. This is why compilers exist, to raise the level of abstraction . For example, other than sidechannels (i.e. Spectre), OOO is not observable , nor is ILP or cache hints. Delay slots are observable at the ISA level but typically compilers do the work of dealing with them. Thank god delay slots didn't make it into programming language…

> Can you imagine if you had a bizarre feature where the next line of code after a branch still executed even if the branch was taken? I seem to recall that there was a mainframe back in the 1970s that actually did that. Univac 1108 or 1100, maybe? Maybe only in some particular mode?

I once worked on the MC88K which had this behavior at the instruction level, and I think other contemporary RISC processors did as well. Never saw it in a higher-level language, though. Maybe some variant of SNOBOL (which already had success/failure branches for every line)?

Re: The x86 architecture is the weirdo, part 2

#152

Post by gumby »

brucehoult wrote: post #142
agalunar wrote: post #122

Earlier quoted context omitted.

> the pervasiveness of the C model has fossilized design decisions of the PDP-11 This is tangential and somewhat pedantic, but I want to point out an oft-repeated mischaracterization. C is essentially a refinement of B with some additions [1], and B was written for the PDP-7, which was a very different machine. For example, the increment and decrement operators in C were inherited from B; they could not have been mod…

>[1] Notably, the char type, since the PDP-11 was byte addressable but the PDP-7 was not. "char" is a useful type for the program's problem domain regardless of whether the machine is byte-addressed or not. Pascal was developed on machines that were not byte-addressable but always had a char type. This is easily visible in the PACK and UNPACK standard functions and the PACKED keyword for arrays and records. It is slo…

Yet all these languages were limited to the 8-bit byte. C on the PDP-10 and -20 only had an 8-bit byte while all other languages on those machines Al had native access to bytes of width 1-36 bits — yes, std::vector in hardware, but more powerful.

Though a general purpose machine it had instructions specifically designed for low cost Lisp implementation, arbitrary numbers of stacks etc…all inaccessible to C

Re: The x86 architecture is the weirdo, part 2

#153

Post by brucehoult »

renox wrote: post #37
KptMarchewa wrote: post #7

Earlier quoted context omitted.

What does ARM and RISC-V spend their weirdness budget on?

In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..

Not really. It's no different to ARM Thumb2 which also has two lengths. NanoMips and IBM 360 have three lengths (16, 32, 48 bits).

I've looked at wide RISC-V decoder design and the variable length is no problem at all out to at least decoding 32 bytes of code per cycle i.e. eight 32 bit opcodes or sixteen 16 bit opcodes, or somewhere between for a mix (average would usually be about 11-12 or so).

You just need 8 decoders that can decode any instruction, plus 8 decoders that only have to understand C instructions. The 16/32 decoders each need a 2:1 mux in front of them selecting either bytes 0..3 or 2..5 from a six byte window. They always output a real instruction. The C-only decoders will sometimes be told just to output a NOP instead [1]. Each decoder type needs a 1 bit input to tell it which option to take. Those inputs can be chained like carries in a simple adder, or they can be calculated in parallel like in a carry-lookahead adder. For an 8-16 wide decode you need a 2-deep network of LUT6 to do this (in FPGA terms .. also not very deep in SoC terms).

Note that this is a VERY wide machine. Possibly well beyond the point of usefulness given typical basic block lengths and what you can sensibly do in the OoO back end. x86 is currently doing 3-4 wide decode, and Apple M1 is doing 8 wide.

In short: no, it's not a problem.

[1] or not output an instruction at all. Outputting a NOP makes it easier to insert the decoded instructions into an output buffer. Then you need to filter out NOPs later -- which is needed anyway, as programs contain explicit NOPs, OoO machinery turns register MOVE instructions into NOPs by just updating the rename tables, etc.

Re: The x86 architecture is the weirdo, part 2

#154

Post by brucehoult »

rwmj wrote: post #59
renox wrote: post #37

Earlier quoted context omitted.

In RISC-V with the C-extension 32bit instructions are 16bit aligned. Far from x86-level of weirdness but my must be quite annoying for those who want to make 'high performance' CPUs..

RISC-V instructions are variable length, from 16 bits up to 192 bits[0]. The instruction stream is self-synchronising though so from a hardware decode point of view it's not a problem, unlike x86. [0] See "Expanded Instruction-Length Encoding" in the user spec.

RISC-V instructions longer than 32 bits are just a theoretical possibility at this point. An extension escape hatch for the future.

No one has done it, no one seems to be keen to be the first to do it, and even how the instruction length encodings work is not a ratified part of the spec -- it's just a proposal at the moment, even for the next step of 48 bit instructions.

There has been discussion of encodings better than the one proposed in the current spec, especially around instruction length encoding schemes that would make more opcode bits available in 80 bit instructions than in the scheme in the spec, so as to have a possibility of encoding 64 bit literals in an 80 bit instruction.

https://github.com/riscv/riscv-isa-manual/issues/280

Re: The x86 architecture is the weirdo, part 2

#155

Post by brucehoult »

pjc50 wrote: post #41
twoodfin wrote: post #36

Earlier quoted context omitted.

There’s a comment on Raymond’s post that explains it in a plausible-sounding way: https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=10... Table-based exception-handling metadata requires function prologue/epilogue sequences to have constrained forms that can be described by that metadata. When NT was first designed for x86-32, there was a lot of existing asm code that people wanted to easily port over to NT,…

> SEH runtime Note that in Microsoft compiler land there are two kinds of exception, regular C++ ones and "structured exception handling". https://docs.microsoft.com/en-us/cpp/cpp/try-except-statemen... The latter does exception unwinding in the kernel on runtime faults (segv, division by zero, etc). It does _not_ unwind destructors or deallocate storage. And yes, I know about this because I had to debug it, on WinCE…

I got bitten porting code to Windows that use setjmp/longjmp not only for exception handling (more correctly: non-local control transfer -- the exception was actually handled by then), but also for implementing a thread library.

The code worked literally everywhere else, but it turned out that on Windows longjmp doesn't just load the registers from the buffer but also does some SEH bollocks. If I recall (and this was in 2006), it didn't matter for the exception handling, but it was a hard crash for switching threads.

So I had to write my own setjmp/longjmp for Windows in assembly language (i.e copy theirs and cut out the SEH bollocks).

Re: The x86 architecture is the weirdo, part 2

#156

Post by DSingularity »

pclmulqdq wrote: post #135
mhh__ wrote: post #133

Earlier quoted context omitted.

I think they don't have a rich enough VC friend, and they need a kick up the arse before (to be blunt) they get too old. Ivan was saying that they weren't sure about how to get money, and then someone quite rightfully pointed out that this is probably the most liquid time in years for funding startups. Mill team if you're reading this: Get your IP sorted out then open source everything, then start talking to VCs aggr…

The mill folks don't care for investment. Most of them are already very rich. They also aren't big on openness: they have a ton of patents.

What’s their end game? Do they ever want a product?

Re: The x86 architecture is the weirdo, part 2

#157

Post by someguydave »

Slighted wrote: post #140
gumby wrote: post #38

Earlier quoted context omitted.

> CPU architectures implicitly have something I call the "architectural weirdness budget" The point of designing a new architecture is you have a point to make (generally, "doing X will lead to faster execution"). So by definition you are adding unfamiliar architectural weirdness, else why get involved. The big problem is that the pervasiveness of the C model has fossilized design decisions of the PDP-11 that still h…

What exactly do you mean by the "C model"? Computers have followed the Von Neumann architecture for quite a long time. That PDP-11 is fundamentally the same as a modern computer, albeit millions of times slower. And I'm curious as well what "new paradigms" you have in mind.

personally I would like a memory access model that makes buffer overflow impossible

Re: The x86 architecture is the weirdo, part 2

#158

Post by brucehoult »

gumby wrote: post #152
brucehoult wrote: post #142

Earlier quoted context omitted.

>[1] Notably, the char type, since the PDP-11 was byte addressable but the PDP-7 was not. "char" is a useful type for the program's problem domain regardless of whether the machine is byte-addressed or not. Pascal was developed on machines that were not byte-addressable but always had a char type. This is easily visible in the PACK and UNPACK standard functions and the PACKED keyword for arrays and records. It is slo…

Yet all these languages were limited to the 8-bit byte. C on the PDP-10 and -20 only had an 8-bit byte while all other languages on those machines Al had native access to bytes of width 1-36 bits — yes, std::vector in hardware, but more powerful. Though a general purpose machine it had instructions specifically designed for low cost Lisp implementation, arbitrary numbers of stacks etc…all inaccessible to C

There is no requirement in C for char to be 8 bits. Even in modern C it's allowed to be bigger than that. For sure it is a bit limiting that in C everything else has to be a multiple (possibly x1) of the size of char. Other languages don't have that restriction.

Algol68 allowed char to be as small as 6 bits, the size on the ICL 1900 it was first developed on (with a 24 bit word size).

Pascal was first implemented on the CDC 6600, with 60 bit words and characters again 6 bits. The first other machine Pascal was ported to was, again, the ICL 1900.

Re: The x86 architecture is the weirdo, part 2

#159

Post by rhn_mk1 »

xenadu02 wrote: post #131
mech422 wrote: post #53

Earlier quoted context omitted.

Oh cool - I never knew this was the reason why... Thanks!

This is mostly irrelevant today though; the hardware is so much faster and memory so much more plentiful that handling is done by reading the full header (and often full packet) then making the routing or forwarding decision. You don't need to squeeze out every single cycle or save every single byte possible. You have so much headroom saving cycles or bytes makes no difference and you can't optimize enough to make si…

That something doesn't make a big improvement doesn't mean that the improvement does not exist.

If I wanted to show where ordering truly does not matter, I would rather look at encoding schemes. Some versions of Ethernet use https://en.wikipedia.org/wiki/64b/66b_encoding , meaning that the smallest unit that can be read at once is 8 bytes. That removes the ordering from IPv4 addresses, but IPv6 can still get handled earlier by taking ordering into account.

Re: The x86 architecture is the weirdo, part 2

#160

Post by snvzz »

CalChris wrote: post #114
snvzz wrote: post #10

Earlier quoted context omitted.

As far as I am aware, RISC-V spends it on not being weird (which is itself weird).

Lack of condition codes when the dominant paradigm (x86, ARM) is condition codes is weird. However, having 32 registers unlike x86_64's 16 makes up for some of it. The base is too base and their bitfield extension is weird.

>The base is too base

I'm sure those that only need the base disagree. For the rest of us, there's G (IMAFD).

Post reply on HN