Lift address-bus width limit to 64 bits.

[MooglyGuy]

This switches the offs_t declaration from u32 to u64, updates the global mask in address_map::map_validity_check, and fixes the compile errors that fell out of the change.

Most of it was associated with logging, so I added explicitly-narrowing casts where most applicable, and switched other situations over from using u32 for addresses to using offs_t.

It would be nice if @pmackinlay would have a look, as ROMP, NS32xxx, and M88x00 had more changes than most.

[pmackinlay]

@MooglyGuy I will take a proper look in a couple of weeks, unfortunately can't until then.

PS: I fat-fingered the "ready for review" button, sorry.

[pmackinlay]

I have had a quick look, and none of the changes stand out in any of my stuff as being problematic. FWIW, Alpha also needs >32-bit physical addresses, and this will allow unwinding an address-space hack. From memory, even mips3 has 34(?) bits of physical space which we currently don't handle.

[cuavas]

In general, I’d change things like this to:

			util::stream_format(std::cerr, "%s: read from bad offset %04x\n", __FILE__, offset);

That way you get type safety, etc. from the strformat.h magic and don’t need the casts.

(This one in particular should be a logerror though, and not have the file name in it – it shouldn’t be sending that stuff to stderr.)

[MooglyGuy]

I'll be happy to address the string_format and stream_format things as a bulk change some other time, as there's a lot more than just these handfuls of spots that need reworking. There are commented-out printfs that have obviously long-since rotted, there are printfs that definitely could be logmacro, a whole bunch of that sort of thing that would be better addressed separately. The intent behind my changes was simply to address each compile error in turn as it came up.

[cuavas]

Same comment for this – to send stuff to standard output with type safety, you can use:

	util::stream_format(std::cout, "address to shiftreg: %08x\n", address);

But the stuff in this device should probably be logmacro.h stuff, not sending stuff to standard output anyway.

[cuavas]

The narrowing is safe in this case since the result is only ever four bits – not sure how much performance impact making idx 64 bits would have.

[MooglyGuy]

Safe or not, it's a compile error on Windows GCC as it weas written. So, you tell me: Should I make it a uint64_t, or should I cast to an unsigned?

[cuavas]

Is it onlyv getting upset because it uses uniform initialiser syntax? Does it also get upset by:

unsigned idx = bitswap<4>(offset, 8, 5, 2, 1);

etc.?

Compilers are weird about when they give narrowing warnings and when they don't.

[cuavas]

Was this new file supposed to be part of this PR?

[MooglyGuy]

Clearly, it was not.

[cuavas]

Keep in mind this will need some non-trivial DRC surgery:

• The emulated memory read instructions (READ, READM, FREAD) need to be changed to treat the second operand addr as 64-bit irrespective of instruction size.
• The emulated memory write instructions (WRITE, WRITEM, FWRITE) need to be changed to treat the first operand addr as 64-bit irrespective of instruction size.
• The C back-end needs to be updated to ensure it stores/retrieves addr as a 64-bit value in its intermediate format.
• The i686 back-end needs to be updated to:
  • Ensure it allocates enough space in each stack frame for the larger arguments for memory access calls (affects HANDLE, RET, entrypoint and exit point generation).
  • Stack addr as 64 bits, adjust offsets for other arguments, and adjust stdcall cleanup.
• The x86-64 back-end needs to be updated to:
  • Make sure it isn’t truncating the global mask, etc. in its address space parameters.
  • Make sure the addr handling is 64-bit clean.
  • Still use 32-bit operand sizes if the global mask fits in 32 bits as the encodings are more compact.
• The AArch64 back-end needs to be updated to:
  • Make sure it isn’t truncating the global mask, etc. in its address space parameters.
  • Make sure the addr handling is 64-bit clean.

[MooglyGuy]

Keep in mind this will need some non-trivial DRC surgery:

As-is it requires no DRC surgery at all, so any of those changes can be tackled without much time pressure.

My aim here is to be able to take a stab at an interpreter core for MIPS R10000, which has a 40-bit physical address bus. Unless someone is sitting on a DRC for a CPU that has an address bus width over 32 bits, it should not be perceived as a blocker.

[cuavas]

Keep in mind this will need some non-trivial DRC surgery:

As-is it requires no DRC surgery at all, so any of those changes can be tackled without much time pressure.

My aim here is to be able to take a stab at an interpreter core for MIPS R10000, which has a 40-bit physical address bus. Unless someone is sitting on a DRC for a CPU that has an address bus width over 32 bits, it should not be perceived as a blocker.

It will still break i686 because the stack layout for calling address space read/write methods changes when the address changes from 32 bits to 64 bits. On Windows i686, the stack pointer will end up at the wrong place because of stdcall adjustment. The function signature change requires calls to be updated.

Thinking about it, this also affects the calls to the debugger instruction hook that the back-end generates, as that has an offs_t parameter.

This will break all CPUs using a recompiler whether they want bigger address spaces or not.

[MooglyGuy]

This will break all CPUs using a recompiler whether they want bigger address spaces or not.

So I simply hallucinated sf2049, panicprk, xfiles, and windheat all booting and running just fine. Got it.

[galibert]

Sounds to me like it's a good reason to get rid of the i686 recompiler. The only reason we kept it was that it was no annoying enough to maintain yet. Blocking 64-bits addresses is annoying enough in my book.