Debugger: Clarification needed on memory access specifiers

[Stevie-O]

Between the source code and the documentation -- mostly the source code -- I've worked out the following understanding of the memory access syntax, which is close to (but not quite):

[[':']<cpuname>.]  [[<lp>]<space>]size [@!] <address specification>

lp bit

The lp bit, which can only specified if space is one of pdi3, seems to be completely undocumented outside the source code; the source code treats this as "l=logical" and "p=physical". What does this mean? Logical or physical from what perspective? It's running in an emulator; nothing is physical.

Memory space meanings

According to parse_memory_operator, there are seven memory spaces:

Mnemonic	Meaning
p	Program (mentioned, mnemonic undocumented)
d	Data	?
i	I/O
3	SPACE3 (undocumented)
o	OPCODE (undocumented)
r	RAMWRITE (undocumented)
m	REGION (undocumented)

What do all of these mean, exactly? What is the distinction between the two?

I would have thought that "program" meant code and "data" meant RAM, except that most debugging operations are interested in looking at RAM, not ROM, yet the documentation (and source code) state that "program" is the default memory space, rather than "data".

Why do o, r, and m lack "logical/physical" mappings?

After I understand what's going on, I'll put together the appropriate documentation updates.

[galibert]

An address space is an address and data bus one can make read and write cycles on. Processors you're used to have one, which we call program. Some processors, like the z80 or the x86, have an i/o space, usually accessed through specific instructions, like 'in' and 'out'. Some processors line the pic have, in addition, an harvard architecture (in opposition to the usual von-neumann), which means the cpu reads the instructions from one bus and read/writes data from another. In that case, we have the instructions in the program space and the data accesses in the data space. And finally some processors (like the 6502, the z80, the 68000, etc) are von-neumann but tell when they fetch an instruction (or some parts of the instruction, the rules vary), which is sometimes used by external hardware to do funky things, often linked to encryption. So for these processors we have an optional (e.g. it exists if you ask for it) opcodes space for these instruction accesses.

These spaces have numbers, 0 for program, 1 for data, 2 for i/o and 3 for opcodes. That '3' you see is thus an historical alias for 'o' ('o' happened after in practice).

ramwrite I'm not sure what it is, and region I dunno how it works. I can only tell you that regions are the places where we load the roms, which are as a consequence not writeable from an address space usually. So it's useful to have a write access to them, but I'm not sure of the syntax.

Finally, logical vs. physical. Modern processors have memory management units (MMUs) which remap the addresses the instructions try to access (logical addresses) to different addresses that are actually sent on the bus (physical). That's used for virtual memory and process segregation essentially. So l/p allows you on these processors and when the MMU is active to choose which side of the MMU you want to be on. Otherwise they're the same thing.

Hope this helps,

OG.

On Wed, May 6, 2020 at 8:43 PM Stevie-O notifications@github.com wrote:

Between the source code and the documentation -- mostly the source code -- I've worked out the following understanding of the memory access syntax, which is close to (but not quite):

[[':'].] [[]]size [@!]

lp bit

The lp bit, which can only specified if space is one of pdi3, seems to be completely undocumented outside the source code; the source code treats this as "l=logical" and "p=physical". What does this mean? Logical or physical from what perspective? It's running in an emulator; nothing is physical. Memory space meanings

According to parse_memory_operator, there are seven memory spaces:

Mnemonic	Meaning
p	Program (mentioned, mnemonic undocumented)
d	Data	?
i	I/O
3	SPACE3 (undocumented)
o	OPCODE (undocumented)
r	RAMWRITE (undocumented)
m	REGION (undocumented)

What do all of these mean, exactly? What is the distinction between the two?

I would have thought that "program" meant code and "data" meant RAM, except that most debugging operations are interested in looking at RAM, not ROM, yet the documentation (and source code) state that "program" is the default memory space, rather than "data".

Why do o, r, and m lack "logical/physical" mappings?

After I understand what's going on, I'll put together the appropriate documentation updates.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/6656, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGSF4LPHDCANN5SYMYT3X3RQGVUJANCNFSM4M2V3G7Q .

[ajrhacker]

@galibert's explanation of the data and I/O spaces tells how those spaces were originally supposed to work. In practice, CPUs may need them for other purposes as well. For instance, the Intel 8048 and Intel 8051 use the data space for internal RAM (which includes the register banks and stack), but the off-chip data that can be read or written to with MOVX needs a different address space that is also distinct from the program space, and so the I/O space was chosen for that. With other CPUs such as the NEC V25, the internal RAM is a non-executable overlay for part of the program space, so it has its own space. (MAME's current memory system lacks a graceful way of handling overlays that can be relocated and removed under software control; changing that has been in the works for a while.)

Some CPUs might need even more address spaces, depending on the architecture and specific hardware configuration; the limit on the number of address spaces in previous versions of MAME have been lifted, and Z8000, as currently emulated, allows six different spaces to be distinguished, though no driver actually uses that many at the moment. I've already noted as a defect that debug commands and watchpoints don't support spaces beyond the standard ones (#5212).

The logical vs. physical distinction may also come into play with CPU architectures that have crude translation mechanisms bolted on to extend the addressing range, such as HuC6280, which uses banking to extend the 6502's 16-bit addresses to 21 bits, or Z80180, which extends the Z80's 16-bit program space to 20 bits.

The "ramwrite" and "opcode" specifiers currently access RAM and ROM areas by bypassing the normal read/write handlers to get at the pointer underlying them instead. This semantic is deprecated and might be done away with in some future version of MAME. In the "opcode" case, it's also obviously a relic of back when opcode fetches weren't implemented as a full-fledged address space (which was done about five years ago).

[cuavas]

Documentation has been updated with explanation here: https://docs.mamedev.org/debugger/index.html#memory-accesses