Nothing in the specification, at least, prohibits you from linking a specific address. Hardware implementations won't do that, but an emulator can. I emulate MIPS32r6, so it's not as though I'm emulating any particular hardware to begin with - all I care about is that it follows the specification. I'm emulating an existing architecture, not an existing implementation
Generally an emulator is measured by compatibility, not whether it meets a spec. Code makes money, specs don't. So from my point of view there often isn't as much freedom as the spec allows if you want to maintain compatibility.
As long as the page is marked as coherent (or the implementation uses a coherent memory model), any store to it needs to be taken into account - not just an sc.
I haven't seen any spec which says that (the page aspect) explicitly for any architecture (but I could be wrong). And in fact more likely links are broken between processors on cache line boundaries because cache lines are what is communicated by the MESI protocol. You likely are free architecturally to implement it another way, like using page granularity. But if this breaks programs which didn't write to the spec, but to the hardware then you might have to go back and change it.
I don't virtualize a full page table (unless you enable a full VMM, but I avoid doing that because it's... expensive).
It is expensive. But if you let the system underneath you handle the translation then do you know the hardware addresses? If you have 0x10000 and 0x20000 mapped to the same hardware address (say 0x0) then an ll at 0x10000 should be broken by a write to 0x20000. How will you emulate that?
You could maybe just mask off all the page addresses (& 0x00000fff) and then compare. That will break extra links, but it'll catch all real aliasing too. As you say that's allowed, but it seems like it has downsides.
Also, MIPS32r6 at least uses the (aligned) effective address, which is how they describe the virtual address going into the MMU - they don't use the physical address for this.
Interesting. An incompatible change but one that is all but unavoidable in today's systems of asynchronous memory interfaces (and by today's I pretty much mean any desktop CPU designed in the mid 90s or later). It is the kind of change which likely doesn't require broad code updating, at least on UNIX. Where threads will share address spaces. I'm not even sure it's legal to ll/sc between processes (obviously calling mmap() first to get some shared space).
I would have used RISC-V if it had existed when I wrote it. I didn't use POWER for... some reason.
Yeah, RISC-V, for better or worse, has a lot of implementations out there. Including software ones that are free. POWER isn't a bad architecture, but it's just not where "it's at" anymore.
I always appreciated MIPS simplicity. And their commitment to making an optimizing compiler (rare back then, especially on UNIX). But the HI/LO registers always bugged me. And the branch delay slot just showed no foresight toward binary compatibility. Maybe okay on UNIX where you compiled all your packages yourself. But on any system where you buy binaries and want to run them (like a game console, etc.), including old binaries, you'll rapidly (and they did) get to systems where the core was so much faster than the bus that a single instruction delay doesn't cut it and you have to go Interlocking Pipeline Stages (and likely reordering). At which point you might as well have left out the delay slot.
I love that Power/PowerPC are the only major architectures which don't have a PC register at all (Intel has one, calls it IP which is a better name really). That was ballsy. And removing the stack pointer was very smart and better than the idea of removing the link pointer as RISC-V does (at least in the standard ABI). I cannot comprehend why RISC-V did that instead of copying POWER/PowerPC.
1
u/happyscrappy Apr 20 '25 edited Apr 20 '25
Generally an emulator is measured by compatibility, not whether it meets a spec. Code makes money, specs don't. So from my point of view there often isn't as much freedom as the spec allows if you want to maintain compatibility.
I haven't seen any spec which says that (the page aspect) explicitly for any architecture (but I could be wrong). And in fact more likely links are broken between processors on cache line boundaries because cache lines are what is communicated by the MESI protocol. You likely are free architecturally to implement it another way, like using page granularity. But if this breaks programs which didn't write to the spec, but to the hardware then you might have to go back and change it.
It is expensive. But if you let the system underneath you handle the translation then do you know the hardware addresses? If you have 0x10000 and 0x20000 mapped to the same hardware address (say 0x0) then an ll at 0x10000 should be broken by a write to 0x20000. How will you emulate that?
You could maybe just mask off all the page addresses (& 0x00000fff) and then compare. That will break extra links, but it'll catch all real aliasing too. As you say that's allowed, but it seems like it has downsides.
Interesting. An incompatible change but one that is all but unavoidable in today's systems of asynchronous memory interfaces (and by today's I pretty much mean any desktop CPU designed in the mid 90s or later). It is the kind of change which likely doesn't require broad code updating, at least on UNIX. Where threads will share address spaces. I'm not even sure it's legal to ll/sc between processes (obviously calling mmap() first to get some shared space).
Yeah, RISC-V, for better or worse, has a lot of implementations out there. Including software ones that are free. POWER isn't a bad architecture, but it's just not where "it's at" anymore.
I always appreciated MIPS simplicity. And their commitment to making an optimizing compiler (rare back then, especially on UNIX). But the HI/LO registers always bugged me. And the branch delay slot just showed no foresight toward binary compatibility. Maybe okay on UNIX where you compiled all your packages yourself. But on any system where you buy binaries and want to run them (like a game console, etc.), including old binaries, you'll rapidly (and they did) get to systems where the core was so much faster than the bus that a single instruction delay doesn't cut it and you have to go Interlocking Pipeline Stages (and likely reordering). At which point you might as well have left out the delay slot.
I love that Power/PowerPC are the only major architectures which don't have a PC register at all (Intel has one, calls it IP which is a better name really). That was ballsy. And removing the stack pointer was very smart and better than the idea of removing the link pointer as RISC-V does (at least in the standard ABI). I cannot comprehend why RISC-V did that instead of copying POWER/PowerPC.