BangersInMyKnickers posted:

The Management posted:

itanium has been dead for years. its VLIW instruction set was garbage and it tried to pawn off a whole bunch of difficult problems on the compiler. well, a compiler that solves those problems well never appeared because it's much harder to solve the problems at compile time than at run time. so while theoretically it was faster in practice it was terrible running real code. it was routinely spanked by x86 processors while using more power. basically it was a total disaster.

echinopsis posted:

can someone give me an explain like i'm 5

like uranium was a whole new instruction set not backwards compatible with x86 but amd just added into x86 to make x64?

Bloody posted:

https://riscv.org/

tty0 posted:

ah yes, you were hoping for something more like x86, but that isn't at all like x86.

The Management posted:

most modern processors have 128-bit or larger vector registers that can do this, including x86_64

rjmccall posted:

the core isa is super-riscy in that "yay we can run a lot of instructions now which is important because it'll take us twice as many instructions to do anything" sort of way. they made sure they covered all the basic c operations but anything even closely related like add-and-test-overflow or add-witih-carry is impossible to do efficiently with the base instructions. but mostly it's like, just read the instruction specifications and you'll see all sorts of bizarre and wasteful crap

like the branch-immediate instruction (jal) has a 20-bit immediate operand, but it's stored in a crazy order where 0bTSRQPONMLKJIHGFEDCBA is actually reordered as 0bTJIHGFEDCBAKSRQPONML for as far as i can tell no reason at all. instructions are 32-bit so the pc is generally required to be 4-byte-aligned but the immediate offset is only implicitly multiplied by 2 so the instruction only has ±1MB range instead of ±2MB. instead of burning 1 bit on branch vs. branch-and-link it burns 5 bits so that you can use an arbitrary gpr as the link register (but you won't get return-address prediction unless you use x1), which i can kindof imagine ways to use but not for anything important enough to justify dropping 4 bits from the range of this instruction. and really it should be 5 because both of these are super-common instructions and it's worth burning a second opcode on them

ok, next. the branch-register instruction (jalr) takes a 12-bit immediate offset. that offset is not scaled at all. the lowest bit of the target address is defined to be ignored, but not the lowest two bits so this can still fail dynamically from mis-alignment. as far as i can tell this immediate exists solely because they wanted to use a two-operand instruction format; i am really blanking on what it would be used for. the spec suggests it could be used to implement fast library calls by doing absolute branches to ±2KB, which is like, yes please let me just give memcpy a small integer absolute address, i am doing research into how easy i can make it to write security exploits

echinopsis posted:

wtf is a smoothebain?

"oh my my brain is deficient in surface area"

RISCy Business posted:

sun servers used to have actual physical keys that you needed to boot the server (i think)

what a weird era