I've since been informed that public domain isn't really a proper term, legally speaking, so to clarify things I've released Torque under the MIT license.

Oh I think I see what you mean now, you're talking about the encoding of the Torque source code that gets fed into the assembler. To be honest I'd never really considered anything other than UTF-8, the parsing is all implemented in Rust which requires strings to be valid UTF-8 anyway. Are you wanting to write Torque code with a non-Unicode text editor, or are you thinking about how the document encoding affects the handling of string literals inside the assembler?

Some kind of table syntax would be useful for character mappings, but I'm not sure what it'd look like or if it'd be applicable outside of dealing with characters. I'll think more on that.

Thanks for the interest! Torque is public domain, feel free to use it or change it or share it however you want. I'd love to hear how people use it, but no obligation.

If you shared it someplace public I'd love to pop by, if you have a link.

I wholeheartedly agree with using "0o" as the octal prefix, I've never been a fan of "0". I've jut implemented this feature and released it in v2.2.0, you can grab it from the project page. Thanks for the suggestion!

I'm not too sure I understand what you're describing with non-Unicode text. Torque doesn't have a built-in concept of bytes, instead each character is treated as an integer with the value being the Unicode code point of that character (using decimal we have 65 for 'A', 955 for 'λ', 129302 for 'robot emoji', etc). It's up to the programmer to choose how to pack the character (integer) into a sequence of bits. Code points are different to encodings like UTF-8 or UTF-16, which define how a code point (integer) is packed down into one or more bytes.

If you want to assemble 7-bit ASCII text, one byte per character, you define a macro that packs each character value into the lower 7 bits of an 8-bit byte. If the string contains a non-ASCII character, the character value will be too large to fit into the field and an error will be displayed.

  %ASCII:c  #0ccc_cccc ;
  ASCII:"This is a string." 

Assembling ISO-8859-1 text would be similar, but would involve remapping the characters above 0x7F like this:

  %BYTE:n  #nnnn_nnnn ;
  %ISO-8859-1:c
    ?[c 0x7F <=]  BYTE:c 
    ?[c '¡'  ==]  BYTE:0xA1 
    ?[c '¢'  ==]  BYTE:0xA2 
    ?[c '£'  ==]  BYTE:0xA3 ;
  ISO-8859-1:"£190.00"

UTF-8 being a variable-width encoding requires a more complicated macro arrangement (you can see an example here [0]). But the key point is that strings aren't treated as byte sequences, they're just character/integer sequences until they get baked down into a byte encoding.

Please let me know if that doesn't answer your suggestion, I'm keen to understand your use-case.

[0] https://benbridle.com/projects/torque/manual-v2.2.0.html#usi...

With character sets, I was initially going to support non-Unicode text by adding a --char-set flag to the assembler, but I decided that the character set should be defined somehow inside each program. My thought was that they could be defined as large table-like macros, something like the following:

  %BYTE:n  #nnnn_nnnn ;
  %CHAR:n
    ?[n 'A' ==]  BYTE:0x01 
    ?[n 'B' ==]  BYTE:0x02 
    ?[n 'C' ==]  BYTE:0x03 
    ?[n 'D' ==]  BYTE:0x04 ;
  
  CHAR:"ABCDABCD"

This is, admittedly, quite unweildy for character sets exceeding a few hundred characters, but it would work passably for small character sets like those used for HD44780-style LCD screens. What character sets did you have in mind?

Octal was another feature I couldn't make up my mind about, just because I wasn't familiar with any architectures that require it. It'll be trivial to tack on though. For the Z80 instruction set, since the instruction encoding tends to cleave along octal lines, I used the following macro to pack octal digits into bytes, which has the advantage of allowing variables to be passed into each digit (the ADDr macro shows how it's used):

  %XYZ:x:y:z  #xxyyyzzz ;
  
  %ADDr:r     XYZ:2:0:r ;  

Thanks for the heads-up about the table of contents, the links should all work now.