Hi Grauw, I've tried to assemble one of my project with -L parameter to obtain a list file to use withr VSCode + Dezog
but I get this error
C:\MSX\asm\Meta>java -jar c:\msx\glass\glass.jar -L metavsc.asm metavsc.rom metavsc.sym
Exception in thread "main" nl.grauw.glass.AssemblyException: Error during assembly.
at nl.grauw.glass.SourceFile.(SourceFile.java:20)
at nl.grauw.glass.SourceBuilder.parse(SourceBuilder.java:88)
at nl.grauw.glass.Assembler.(Assembler.java:67)
at nl.grauw.glass.Assembler.main(Assembler.java:58)
without -L parameter all works fine
Hey thegeps, the -L parameter expects an output filename to follow it, as you have it now it uses metavsc.asm as list file output and and tries to load the .rom file as assembly source.
p.s. I’m not sure Dezog supports Glass’s list file format… Last time we talked about it, iirc it didn’t completely work yet.
So there is an output filename missing... i don't know why I thought it wasn't needed...
About glass's list file support... I thought it was added by S0urceror since version 1.3.3 (second openmsx release), as stated here:
https://github.com/S0urceror/DeZog/releases
If I can't debug my projects using DeZog. I will continue using OpenMSX Debugger.
I'm migrating from a simple text editor (TED) to VSCode and it would be nice to have a complete integrated toolchain
I’m also using VSCode, it’s a great editor. The extensions I use for Z80 programming are:
- ASM Code Lens by maziac
- Z80 Assembly meter by Néstor Sancho
- Hex Editor by Microsoft.
Someday I would like to to add a language server to Glass so that it can be used for code completion and highlighting in VSCode and other editors that support the protocol.
Oh, that would be great!
I'll go and take a look to the extensions you are using. Thanks for listing them 
Hi Grauw,
Again my appreciation for your glass-compiler. Currently I am working on a z80 language extension in order to enable object-oriented programming techniques. Underwater glass is used for the main compilation. Its input is a pre-parsed file based upon the new language.
So far so good, I think you like it and will gladly show it to you in person (maybe on a next msx event?)
However, the symbol output of glass did make me puzzle. It might be a bug / I might did something stupid. Here are some examples. Hope you are able to help.
Example input asm
org #0100
system: PROC
__address: equ main
main: PROC
__procLabel: equ $
ld b,60
loop: halt
djnz loop
ret
ENDP
ENDP
Example output symbols
system: equ 100H system.__address: equ 100H system.__address.__procLabel: equ 100H system.__address.loop: equ 102H system.main: equ 100H system.main.__procLabel: equ 100H system.main.loop: equ 102H
What puzzled me was the generation of the symbols 'system.__address.__procLabel' and 'system.__address.loop'. My post-glass parser fails when these labels are generated. I managed to fix this by changing the 'equ main' into 'equ main+0'. Doing so these labels disappear...
Example output symbols (fixed with equ main+0)
system: equ 100H system.__address: equ 100H system.main: equ 100H system.main.__procLabel: equ 100H system.main.loop: equ 102H
An second strange thing is the crash of the glass-compiler (stack overflow) when the equ of the line holding the '__procLabel' is changed from 'equ $' into 'equ main'.
Kind regards,
Stephan Smetsers
Note:
I'm using glass-0.6.jar
What puzzled me was the generation of the symbols 'system.__address.__procLabel' and 'system.__address.loop'. My post-glass parser fails when these labels are generated. I managed to fix this by changing the 'equ main' into 'equ main+0'. Doing so these labels disappear...
In Glass all non-equ symbols reference objects, e.g. a single instruction, a macro, or in case of main it references the procedure object that starts at PROC and ends at ENDP. Because they are objects you can reference the symbols inside, like main.loop, etc.
Additionally, all equ symbols make the symbol exactly equal (an alias for) the term on the right hand side. This can be a literal, or in the case of equ main, an object or literal referenced by another symbol. So you have __address pointing to the same object as main does.
If you use the object in an arithmetic expression it will take the address of the object, so main+0 yields a number and no longer an object. The shortest form to explicitly take the address of an object would be +main.
When it serialises the symbols to a symbol file, for symbols that reference objects it will also recurse to serialise the values of the fields inside the object. It doesn’t distinguish between aliases, so this can mean that values will be output repeatedly under different names. If you want the symbol file to contain a symbol with only the address of an object, you indeed need to cast it with e.g. +.
An second strange thing is the crash of the glass-compiler (stack overflow) when the equ of the line holding the '__procLabel' is changed from 'equ $' into 'equ main'.
Ah, yes. That probably doesn’t crash if you don’t generate a symbol file, right?
As I mentioned, when it serialises the symbols, for symbols that reference objects it will also recurse to serialise the values of the fields inside the object. When a field of the object refers to the object itself, there is a circular reference and during the serialisation this means it will recur infinitely into itself. Probably the symbol serialisation should have a check for recursion, although that could mean __procLabel would be omitted.
I did not realise that an equ could be used in that way. It explains the additional labels. Since the to-number conversion is also working you get the best of two worlds. Using an alias would be usefull to reduce long label names on usage (especially when using macros within a macro to mimic structs).
Ah, yes. That probably doesn’t crash if you don’t generate a symbol file, right?
Correct! But the example I mentioned was stupid anyway. However it might might might occur when you define a macro within the proc in which you use it via an alias.... I think nobody will do that!
Ah, yes. That probably doesn’t crash if you don’t generate a symbol file, right?
Correct! But the example I mentioned was stupid anyway. However it might might might occur when you define a macro within the proc in which you use it via an alias.... I think nobody will do that!
A graph with possible cycles can inherently not be converted to a flat list like a symbol file, but that still shouldn’t make it crash probably. Luckily it isn’t common but it would be better to check for it.
Edit: now it checks.
I’m also using VSCode, it’s a great editor. The extensions I use for Z80 programming are:
- ASM Code Lens by maziac
- Z80 Assembly meter by Néstor Sancho
- Hex Editor by Microsoft.
Someday I would like to to add a language server to Glass so that it can be used for code completion and highlighting in VSCode and other editors that support the protocol.
I find this extension pretty helpful: Z80 Instruction Set
