51–60 of 92 posts
I feel sudden urge to write some assembly for fun. Have not done it for at least a couple of years I think.
[1] https://store.steampowered.com/app/370360/TIS100/?curator_cl...
[2] https://store.steampowered.com/app/504210/SHENZHEN_IO/?curat...
This complexity is pushed down to operating systems, compilers, assemblers, debuggers. It ends up causing brutal human time overhead throughout the chain, and its cost effectively prevents security and high assurance.
This more than justifies moving away from x86 into RISC architectures, such as the rising open and royalty-free RISC-V.
I feel sudden urge to write some assembly for fun. Have not done it for at least a couple of years I think.
Whenever bored, I read or watch chibiakumas tutorials. There's no such thing as knowing too many assemblers.
The only real answer is: Too Many. This complexity is pushed down to operating systems, compilers, assemblers, debuggers. It ends up causing brutal human time overhead throughout the chain, and its cost effectively prevents security and high assurance. This more than justifies moving away from x86 into RISC architectures, such as the rising open and royalty-free RISC-V.
Of course, these days the Z80 instruction set looks trivial :-)
Earlier quoted context omitted.
It's not that variable length is expensive, it's that variable length the way Intel does it is expensive. For instance — not that this is a good idea — you could burn the top 2b to mark instructions as 2/4/6/8 bytes (or whatever) in length. Then you can have your variable-width-cake-and-eat-your-fast-decode-too.
Could you elaborate - what is about the Intel design that makes the decode so inefficient? Is "2b" bits here? Are there examples of ISA or chips that handle variable length instruction encoding efficiently?
I think this old Intel patent talks about one of their decoder implementations:
Earlier quoted context omitted.
These days RISC is mostly about regular encoding of instructions which don't present challenges to doing precise interrupts on a deeply pipelined machine rather than just few instructions per se .
What do you mean by "precise" interrupts here? Do some types of interrupts cause worse pipeline stalls than other types? Are the interrupt handlers in RISC faster because of more efficient decoding? Is that the issue?
In the modern day it mostly just means that you can implement fancy out of order schenanigans with a bit fewer engineer-years than non-RISC ISAs.
Earlier quoted context omitted.
These days RISC is mostly about regular encoding of instructions which don't present challenges to doing precise interrupts on a deeply pipelined machine rather than just few instructions per se .
What do you mean by "precise" interrupts here? Do some types of interrupts cause worse pipeline stalls than other types? Are the interrupt handlers in RISC faster because of more efficient decoding? Is that the issue?
https://dl.acm.org/doi/10.1109/12.4607
"An interrupt is precise if the saved process state corresponds to a sequential model of program execution in which one instruction completes before the next begins. In a pipelined processor, precise interrupts are difficult to implement because an instruction may be initiated before its predecessors have completed."
I feel sudden urge to write some assembly for fun. Have not done it for at least a couple of years I think.
Then you might like TIS-100 [1] and Shenzhen I/O [2]. [1] https://store.steampowered.com/app/370360/TIS100/?curator_cl... [2] https://store.steampowered.com/app/504210/SHENZHEN_IO/?curat...
Earlier quoted context omitted.
Then when checking the results are half the speed of what the compiler spits out and the fun is gone. At least that's what happens to me...
I've always been able to beat the compiler, and that's usually after trying to optimize using C. Admittedly, it's a whole lot harder to understand what's fast than it used to be. Access to SSE has it's own benefits. It's been a problem (optimizing) for some time though. I remember it being some work to beat the compiler on the i960CA. OTOH, I seem to remember the i860 being not-so-great and for sure the TI C80 C comp…
Also, the programmer can "cheat" by doing things the compiler would consider invalid but are known to be ok given the larger context of the application.
The restrict keyword in c gives an example of how one can optimize code by knowing the larger context. https://cellperformance.beyond3d.com/articles/2006/05/demyst...
The problem is the ROI is usually pretty bad as these assumptions rarely hold as the code evolves, in my experience, and the optimization usually only lasts for finite (sometimes shockingly short) amount of time. i.e. OS changes, hardware changes, memory changes, etc. etc. etc.