Support Multiple Charmaps/Disable Charmap

[RenaKunisaki]

Right now it looks like charmap overrides any previous mapping including ASCII. This means you can't have more than one mapping, or use ASCII and a custom map in the same ROM (eg for debug output form emulators). Would be great to have a way to specify which mapping to use for a given string or group of strings.

[aaaaaa123456789]

How would you do this?

[Sanqui]

One way to do this would be a setcharmap directive, which would switch the behavior of charmap and db. A disadvantage is that it introduces state.

    setcharmap ascii
    charmap "A", $41
    charmap "B", $42
    
    setcharmap game
    charmap "A", $10
    charmap "B", $11

    setcharmap game
    db "Game string@"
    setcharmap ascii
    db "ASCII encoded string"

Then you could make macros such as

ascii: MACRO
    setcharmap ascii
    db \1
    setcharmap game
ENDM

    db "regular text"
    ascii "ascii text"

[dbrotz]

setcharmap looks like a good idea to me, but I have some questions.

What about the "default charmap" that exists before you use setcharmap? How do you return to it after switching? Should we just give it the name "default"?

; implicit default charmap
charmap "A", $10
charmap "B", $11

setcharmap other
charmap "A", $20
charmap "B", $21
db "A"

setcharmap default
db "A"

Another thing to consider is the state that a new charmap starts off with. Does it inherit the current charmap's mapping or start with some predefined initial mapping (e.g. ASCII)?

[ISSOtm]

I would agree with hardcoding the default charmap to default (ie. that charmap is implicitly created and loaded by the assembler when beginning assemby).

I think creating a new charmap should inherit from the current one, that way if you want to base it off the default mappings you simply do setcharmap default beforehand, and it allows making "base" charmaps that deduplicate some charmaps' common parts.

[dbrotz]

That sounds good to me.

Another thought I just had is that we might want to distinguish between creating a new charmap and switching to an existing one. The benefit is that it might help catch errors where someone thinks they're creating a charmap but they're switching to an existing one or vice versa. The downside is that there would be more directives to remember.

Specifically, newcharmap x could be used to initially create the new charmap called "x" and then setcharmap x would switch to it. If you used newcharmap x twice or if you used setcharmap x before newcharmap x, you would get an error. The alternative would be to just have setcharmap x and create the "x" charmap on its first use and switch to it on later uses.

[dbrotz]

Also, I don't think my suggestion of "default" is the best idea. It could be confusing because it sounds like it would be the charmap that the assembler begins with, without any changes. "main" would be a better name for it.

[ISSOtm]

Well, that charmap is the one the assembler begins with, isn't it?

The problem with requiring a newcharmap is that it might not be backwards-compatible. Maybe a clearer name for setcharmap would be usecharmap, or switchcharmap? That way it stays akin to what it is now and would just be a context switch.

It does mean that you can keep defining a charmap as you go, which isn't very clean, but that's already what happens with the current system.

Lastly, you can decide to break backwards compatibility in that regard (hopefully in a mild manner), and keep this feature for 0.4.0.

[dbrotz]

Yes, but to me, "default" sounds like it's what the assembler begins with, without any modifications by the user. I was thinking that you would start with the "main" charmap already in existence and be able to use charmap to alter it, to maintain backward compatibility. You would only use newcharmap if you wanted to have more than one charmap.

[ISSOtm]

The thing I'm slightly worried about is, to maintain backwards compatibility, the main charmap would be special-cased to be modifiable at any time.

[aaaaaa123456789]

Under the risk of making suggestions to an issue that already has a pull that closes it, how about this?

1. Define charmaps as a block, just like everything else is defined:

    game: CHARMAP ; reusing the keyword shouldn't be a problem, but change it if needed
      charmap "A", $01
      charmap "B", $02
    CEND
   

2. Use charmaps with setcharmap, as proposed; use the assembler's default charmap by passing no name at all (which removes the need to hardcode a name):

      setcharmap game
      db "AB" ; db $01, $02
      setcharmap
      db "AB" ; db $41, $42
   

Note that the assembler's default charmap would still be modifiable via charmap statements. This isn't really a problem for ASCII-users, as they can declare a new empty charmap for ASCII.

This proposal eliminates accidental charmap definitions, as definitions and usage look nothing alike. It still has the problem of state, though.

EDIT: one way of eliminating the state issue would be to introduce yet another block that creates a charmap scope:

  charmap game
    db "AB" ; db $01, $02
  endc
  db "AB" ; db $41, $42

This would only really work for occasional usage of alternate charmaps, though. It also introduces yet another overload for charmap (0 arguments: begin charmap declaration block, 1 argument: begin charmap scope block, 2+ arguments: declare character), but that shouldn't be an issue; if it is, use separate keywords.

[dbrotz]

I think the charmap definition block could be good. It looks odd that you have to repeat CHARMAP on each line inside the block, though. It would still be nice to be able to inherit another charmap somehow, as well.

[ISSOtm]

Either the charmap could inherit from the current one (charmap text then jp_text: CHARMAP), or explicitly inherit from one (jp_text: CHARMAP text).

[dbrotz]

When I tried putting charmapdef : T_LABEL ':' T_POP_CHARMAP in the grammar, it added an extra shift/reduce conflict.
There really isn't any reason to put a label before the current CHARMAP directive, but it was allowed. Using the same keyword will break any code did something like this:

label: charmap "a", 1

Is it worth using a new keyword to avoid that?

[ISSOtm]

Using a new keyword would make more sense (so as not to overload the charmap keyword with too much sense), but it could break code that used such a macro.

I'm starting to doubt the practicality of introducing a new variant of this construct, actually.