One place I know it is used as filler is when creating something that runs as a "complete" Z80 program - that is, something like an operating system for the calculator or a Master System ROM.

In any case, some sort of directive to allow people to relocate the PC and output the filler bytes would be useful. .orga (absolute origin) is used by WLA-DX to set an absolute origin within the ROM (as opposed to a relative one within the page) so is not a good idea.

Regarding internationalisation issues I think allowing any letter outside the English alphabet is a bad idea, except for comments and string literals. I presume that the default mapping for strings is a TIOS-friendly one. If there’s no mapping defined for a character, you should signal an error and not try to emit utf-8 or anything like that silently (it’s not clear to me what you planned here).

A minor issue: in my humble opinion allowing the d suffix for decimals creates potential problems without adding anything of real value. Everyone remembers the famous broken ION headers, but who uses this notation for decimal numbers otherwise?

Also, I guess that forward references shouldn’t be allowed in expressions after .org directives.

Expression handling seems to be generally fine this way. It’s indeed easy to establish two-way communication between Brass and the language specific assembler plugin. On the other hand, I don’t see why you’d like to constrain operator tokens. For instance, I’m of the weird kind who prefers the arrow notation for autocopy instructions. The current system can’t handle that.

Regarding internationalisation issues I think allowing any letter outside the English alphabet is a bad idea, except for comments and string literals.

It would probably cause the least confusion.

Quote:

I presume that the default mapping for strings is a TIOS-friendly one.

No, as the TIOS mapping is pretty mental. Rather than having a fixed table, I'll use a hash table which maps a char to a char (char as in 16-bit character, not as in C's "byte" type). This table would be empty at the start, however...

Quote:

If there’s no mapping defined for a character, you should signal an error and not try to emit utf-8 or anything like that silently (it’s not clear to me what you planned here).

...in this case, it might be sensible to substitute in the "original" value if the input character code is between 32 and 127, otherwise display an error.

Quote:

A minor issue: in my humble opinion allowing the d suffix for decimals creates potential problems without adding anything of real value. Everyone remembers the famous broken ION headers, but who uses this notation for decimal numbers otherwise?

I'm not sure what problems could be caused, nor am I aware of the broken Ion headers, but I do see your point. I'll remove it.

Quote:

Also, I guess that forward references shouldn’t be allowed in expressions after .org directives.

Well, absolutely.

Quote:

Expression handling seems to be generally fine this way. It’s indeed easy to establish two-way communication between Brass and the language specific assembler plugin. On the other hand, I don’t see why you’d like to constrain operator tokens. For instance, I’m of the weird kind who prefers the arrow notation for autocopy instructions. The current system can’t handle that.

I'm aware that some assemblers will have to hack about with the input - for example, with the Z80 index instructions the Z80 plugin would have to remove the IX or IY token before the expression is evaluated. I'm not sure what that means for the arrow notation (not that I've ever seen the arrow notation)...

No, as the TIOS mapping is pretty mental. Rather than having a fixed table, I'll use a hash table which maps a char to a char (char as in 16-bit character, not as in C's "byte" type). This table would be empty at the start, however...

I imagined so, except for the initial empty state.

benryves wrote:

...in this case, it might be sensible to substitute in the "original" value if the input character code is between 32 and 127, otherwise display an error.

At least that much, yes. And I think you should add as many characters as possible to the initial table (like Greek letters with TIOS support).

benryves wrote:

I'm not sure what problems could be caused, nor am I aware of the broken Ion headers, but I do see your point. I'll remove it.

I'm aware that some assemblers will have to hack about with the input - for example, with the Z80 index instructions the Z80 plugin would have to remove the IX or IY token before the expression is evaluated.

Why is that a problem? Expressions are nicely tokenised and passed in a structured form. You can’t really avoid that with a general parser.

benryves wrote:

I'm not sure what that means for the arrow notation (not that I've ever seen the arrow notation)...

I’ve come across these notations so far, and I was thinking of the last one:

I'm not so sure I'd want TIOS-specific mappings to be part of the assembler. I'd certainly put them in a template, though.

Though, "" is treated as a translated string and '' is treated as an untranslated string. For the untranslated version, do we just truncate to whatever size we want (be it a byte or a word)?

And yes, I do remember the 6d incident now.

I found your Excel spreadsheet with opcodes yesterday and noticed that syntax there. Every other document only mentions the other two, though I'd agree the arrow notation is the 'best' (and isn't misleading, like the 'ld' one).

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum