I try to be as supportive of OOP style in Glass as I can, because it is how I write my software myself. However things like polymorphic calls and how objects are created etc. is more about the libraries and implementation choices of code and not so much about the assembler itself.

E.g. there are several ways to instantiate objects, statically, on a heap, with or without a template, etc. And there are also several ways to do virtual calls, with different performance, memory usage and flexibility trade-offs. The assembler isn’t much of a help there except to try and facilitate it.

There are some syntactic sugar things where Glass is helpful here, e.g. being able to pass ClassTest into the Class definition macro, to determine its size, instantiate a template, and to reference .New and .Delete static members on it. In principle OOP can be done in any assembler, however definitely I started work on Glass to simplify the syntax of these things for me.

Checking Glass for my (new) project now. I was wondering why there is a 0x... for hex notation but no 0bxxxx for binary. Coming mainly from C coding, i didn't get why that was no option, while other options are available like #$ and %?

I reluctantly added the 0x support that was submitted because there’s one or two assemblers (e.g. Sjasm) which support it as well, so there was some argument for interoperability with them. However it’s not standard assembly syntax at all, so code using the 0x prefix will not be portable, and 0b even less so. I don’t think it’s good to introduce more C syntax into assembly (like 0b or // comments).

I don’t recommend using 0x. I recommend to use H and B suffixes, or # / $ and %, which are fairly universally supported. You will get used to it very quickly.

Just a noobisch question.
1000H is fine
9000H is fine
but A000H gives an error
seems it needs a leading zero, so 0A000H
Can you please tell me the story behind this?
When do you add this extra zero and why?
loading 16bits registers require a extra 8 bit?

I can't answer it for Glass. But it was a common restriction of old assemblers that numbers needed to start with a digit and end with a letter defining the base (if non-decimal). This does not add a byte at all (or a nibble) to your program. Maybe Glass is enforcing that 0 (zero) or maybe it is a glitch. It just made it easier to parse the files in machines with very limited memory. Today it may feel a little nonsensical.

It’s certainly not a glitch, nor has to do with limited memory . Every assembler requires this extra 0 for H/B suffix notation, and there’s a very logical reason for it:

In the grammar of assembly language, every symbol (label) starts with a letter, so number literals can not. Otherwise they are not distinguishable. E.g. consider a symbol ADDH, it would be very surprising if that would be generating the number 2781. A000H is a symbol as well, not a number.

If the leading 0 bothers you, you can also use # and % prefixes, which don’t require a leading zero because the prefix already distinguishes it from a symbol.

p.s. This isn’t an extra 4 bits, A0 and 0A0 are the same number, just like in decimal 0010 is exactly the same number as 10. Glass actually stores 32-bit numbers internally, and truncates them to 8 or 16-bit when output. This is so you can do math more easily (like 1000 * 555 / 111) without running into precision problems.

Every assembler that I know works like this (Gen80, M80, Compass, Pasmo, Sjasm, MASM, …), and there’s no way to support that other than either forbidding symbols that match “[A-F][0-9A-F]H”, breaking compatibility with sources for other assemblers, or only trying to parse undefined labels as hex, which can lead to very unexpected programming bugs. Not to mention complicating the parsing rules. I also don’t see a need for it, if people don’t like it then they can use # and % notation which is the second-most universal syntax. Are you saying that tniasm does one of those two things?

One syntactic thing I think is strange is that the colon after a label is optional. I don’t understand why that is. I support it for compatibility’s sake, but it unnecessarily complicates the grammar and parsing, and reduces consistency in the source code you write. So yeah, I don’t like those at all. The support for colon-less labels is the reason why instructions must be indented with white space (because at the moment of parsing I can’t distinguish a label without colon from an instruction or macro). Which is good practice anyway, but still it’s annoying that it matters.

I removed the address out of range check recently in development builds, it was more annoying than useful (your specific example being one of the common encounters). Now the address will just wrap around. However the current released version of Glass doesn't have that change yet.

In Glass 0.5 you can work around it by putting a few ORG directives between the ds'es at the top, resetting the address counter so that it never goes above 64K.

There’s no block comment in assembly syntax. However many editors have a multi-line editing function, in Visual Studio and Notepad++ this is ALT + click-drag, in Eclipse this mode is activated by ALT-SHIFT-A. That way you can easily add or remove a ; in front of many lines at once.

But as you showed you can also omit the & 0FFH since the value is clipped down to 8 bits anyway. It’s a matter of preference, how explicit you want to be. Personally I prefer to be explicit because that works in all contexts (also calculations and 16-bit loads), and the pattern of >> 8 and & 0FFH is very recognisable so the intent is clear quickly.

p.s. Here’s what I do the other way around, composing a 16-bit value out of two 8-bit ones:

The macros in Glass are not treated like preprocessing directives as in other assemblers, so variables can’t be “pasted” into labels or strings like that.

There are two things here, firstly the string concatenation, in db pseudoinstructions you can combine strings with the , operator but that doesn’t work for incbin at the moment. I should add that, shouldn’t even be very difficult, so I’ve made an issue for it. I don’t think I’ll have time for it before the Nijmegen fair next week, but I should be able to after.

Secondly, labels can’t be built from strings. However they do exist in the scope of the macro, so you can define the macro like this and access the fields inside as a structure:

But as said, the string concatenation doesn’t work yet, so until I implement that you’d need some other way. One option is to not use a macro for this for now and copy/paste the code that’s currently in it. Alternatively you could consider though to concatenate the six files into one so they can be included in one go, and make a macro just for the offsets in it:

Having fun in glass.
But it would be cool to have some kind of general reporting.
WARNING could work
But just a general PRINT
and the possibility to do something like:
PRINT ?define_LastRomByte
PRINT ?code_Lenght
or PRINT "Codelenght: "?code_Lenght
would be awesome!
I know the .sym is there but (calculated) equ's are not in the file.
I guess this could be an easy one since WARNING is already there??
When you have time? Sometime?