Glass Z80 assembler

Page 20/21
13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21

By thegeps

Paragon (1062)

thegeps's picture

03-04-2022, 20:08

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

By Grauw

Ascended (10618)

Grauw's picture

03-04-2022, 21:46

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.

By thegeps

Paragon (1062)

thegeps's picture

03-04-2022, 22:17

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

By Grauw

Ascended (10618)

Grauw's picture

03-04-2022, 23:40

I’m also using VSCode, it’s a great editor. The extensions I use for Z80 programming are:

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.

By thegeps

Paragon (1062)

thegeps's picture

03-04-2022, 23:32

Oh, that would be great!
I'll go and take a look to the extensions you are using. Thanks for listing them Smile

By inchl

Expert (65)

inchl's picture

05-08-2022, 23:12

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

By Grauw

Ascended (10618)

Grauw's picture

07-08-2022, 15:31

inchl wrote:

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. +.

inchl wrote:

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.

By inchl

Expert (65)

inchl's picture

08-08-2022, 13:19

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).

Quote:

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!

By Grauw

Ascended (10618)

Grauw's picture

08-08-2022, 16:39

inchl wrote:
Quote:

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.

By Thom

Paladin (696)

Thom's picture

10-08-2022, 12:26

Grauw wrote:

I’m also using VSCode, it’s a great editor. The extensions I use for Z80 programming are:

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

Page 20/21
13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21