> There are several 48-bit instruction possibilities.
> 1. PC-relative long jump
> 2. GP-relative addressing to support large small data area, effectively giving GP-relative access to entire data address space of most programs
> 3. Load upper 32-bits of 64-bit constants or addresses
> 4. Or lower 32-bits of 64-bit constants or addresses
> 5. And with 32-bit mask
> 6. More effective ins/ext of 64-bit bit fields
Another thing thats offten discussed is moving the vtype and setvl into each vector instructions, I'm not sure if that requries 48 or 64 bit instructions.
> 1. PC-relative long jump
My understanding is that these are rare
> 2. GP-relative addressing to support large small data area, effectively giving GP-relative access to entire data address space of most programs
What is 'GP' here? but "...access to entire data address space of most programs" In this case you are just going to be bouncing all over the address space, substantially missing any level of cache much of the time, surely?. Maybe you get a little extra code density but you aren't going to get any extra speed to speak of.
> 3. Load upper 32-bits of 64-bit constants or addresses
> 4. Or lower 32-bits of 64-bit constants or addresses
> 5. And with 32-bit mask
Well yeah, but how common is this? I understand the alpha architecture team looked at this and found it uncommon which is why they were okay with less-than-32-bit constants. If it really speeded things up you might build a specific cache to store constants (a kind of larger, stupider, register set). It would seem a simpler solution.
I'm not sure what you mean with 6, and I'm not familiar with vtype/setvl
Depends on how many bits you had to start with. On Power ISA they aren't common either, but when they happen you need up to seven instructions (lis, ori, rldicl, oris, ori, then for branches mtctr/b(c)ctr) to specify the new address or larger value. Most other RISCs are similar when full 64-bit values must be specified. This is a significant savings.
Often one vsetvl stays valid for multiple/most/all instructions, but sometimes there's a need to toggle it for a single instruction and then toggle it back. With 48-bit or 64-bit instructions, such temporary changes could be encoded in the operation instruction itself.
Additionally, masked instructions always mask by v0, which could be expanded to allow any register (and perhaps built-in negation) by more instruction bits too.
You could have a lot more registers.
The first example, I'm not sure you'd want a full 64bit encoding space. You still aren't going to be able to load a 64bit immediate directly so I'd rather see an instruction that uses the next instruction as the immediate. But then 50% of the time you're still going to be padding this to 64bit alignment, so it's unclear to me that this is a benefit over 2 lots of the same but with 32bit immediates.
The second option is interesting. But if you've got 256 addressable registers say, what use are the 32 and 16 bit instructions that can only address a tiny proportion of those registers.
On the flip side, the ability to have more registers is very good for SIMD/GPU applications.
But if you have a processor that also uses 16 bit instructions those extra registers become unusable. Thumb can't encode all registers in all instructions so you have the high registers that are significantly less useful than the low registers.
X86 is the same, never really done 64bit ASM so I don't know if they improved that.
So then you may aswell just divide up the registers so you've got 16 general purpose registers and 16 registers for simd or whatever.
I suppose the os could reserve registers for itself to save swapping in and out quite so often.
Register windows for applications/functions/threads.
Or maybe something radically different, like get rid of the stack, and treat them conceptually like a list?
Very revealing, thanks, this had never occurred to me
https://www.talospace.com/2021/04/prefixed-instructions-and-...
What does 'rare' mean here, does it mean rare in execution, or rarely appears in code? (The difference being that something might only appear once in your code but be part of your hot loop so be executed any number of times)
If they are rare in execution, what is their value over composing them of 32-bit instructions, where the (rare) overhead of doing so would be typically a amortised away?
(The only thing I can think of that 64 bit instruction seem suited to is some kind of internal CPU management instructions, but context switches etc. are relatively rare & very expensive anyway so... I don't know)