0xSCA -- unclear/ undefined behaviour

[apuch]

Hello,

I'm was reading ASM/Spec_0xSCA and thinking about an own implementation (yes, me to;) ) But I have some questions/ requests about clarification. If this will become the standard reference for the dcpu16-asm, it should be right quit from the beginning.

Generally:

• is an assembler still 0xSCA-compilant, if the handling of warnings (SHOULD report .. etc) can optionally be set more restrictive? ( -Werror in gcc)
• value I: how to state octal [0xxx] ? how to state binary [0bxxxxx]?
• value II: is -0xFF allowed? (for example `42 + -0xFF') -- I hope not

4.3.1.1. Code

• MUST the inclusion fail, if there is no implementation defined file for inclusion? (C will look for a local file)

4.3.1.2. Binary
If I read a binary bytewise, should it be big endian or little endian? V1.7 states little endian for all multibyte-operations and should also be used here I think. But it should be stated explicitly.

4.3.2.
"Any occurrences of the definition during its existence, MUST be replaced with the given value to the definition." and MAY be emitted (?)

4.3.3.1. Ascii Literal Flags
How shall incompatible flags be handled?

flag a: how to handle strings with more than 255 bytes?

4.3.7. Conditionals

" .. then expression = 1 MUST be assumed. "
1st: Please use == or equal to make it more clearly
2nd: why not !=/ unequals 0 like in C? This should made it more simple to
use binary flags.

4.3.8. Error reporting/ 4.3.10. Echo general output

• may we want to introduce a .warning?

5.2. Inline character literals
(also applies to string-handling to (4.3.3.1. Ascii Literal Flags)

• How should ASCII-values above 127 be handled?
• How to represent whitespace-literals? (tab, cr, lf, backspace, ...)
  proposal: just like in C ;)

6.0 Inline arithmetic

• How many bytes must be supported? [ eg. (((A << 256) & (B << 256)) >> 256) > 0 ]
• please define a the precedence of operators.
• ==, !=, <>, <, >, <=, >= -- the result should be either 0 or 1. At the moment, its undefined.

All in all: The compiler should be defined to be compatible to notchs assembler and to 0xSCA (the former without notice, the later with warnings about deprecated usage). Everything else, including undefined behaviour, should fail. Without an option for recovery and without a binary or something else as a usable result. Broken assembly IS broken.

regards
Peter

[mleise]

Before posting my own critics, I read yours just to find there are no overlaps. I hadn't thought of all your good findings, except for the big-endian/little-endian issue when reading packed binary data.

If I may comment on part of the string representation issue, I think we should call the alpha-numerics and the matching punctuation symbols ASCII, and that's about it. Tabulator, carriage-return, new-line, ... all those don't exist in the charset of the 0x10c universe, which has it's own 7-bit character encoding, where all control-characters from ASCII are replaced with printable characters. For example, if you had a string with "abc\tdef" it would print as "abc┌def". Instead we should support both "\x09" and "┌" instead of "\t" - which is misguiding. But I'm fine with the spec being open about unicode -> 0x10c screen mappings. Just a "\x09" should be possible and supported by the spec, if plain ASM source code is required to be ASCII encoded or for Notch's strange symbols that match no Unicode symbol.
If you want to handle key-codes instead (which includes backspace), that's another story. I would just store the non-printable ones (read: invisible) as numbers in ASM code (except for ' ').
P.S.: There is no "ASCII above 127" ;-)