Glass Z80 assembler

Page 12/16
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16

By spacemoai1973

Master (165)

spacemoai1973's picture

16-02-2020, 21:26

Metalion wrote:

When I was starting on assembly langage in the '80s, the only format I knew and that was quite universal was the $ format. It was used everywhere, and I do not remember seeing a lot of alternate formats around.

You must have started with the 65xx or 68K CPUs, which indeed use $-prefix format. It was not used "everywhere" but only there.
Intel and ZiLOG CPUs have always used h-suffix format.

Some MSX-specific assemblers support BASIC's &H prefix, and most cross-assemblers support C-style format as well.

By Grauw

Ascended (9072)

Grauw's picture

23-02-2020, 16:55

spacemoai1973 wrote:

I just point out that at least one assembler exists that succesfully solves the described problem so that can be taken into account in the question of how to move forward.

Well the multitude of bin/hex literal prefix/suffix options isn’t a problem per se, it’s mostly just an annoyance from a “clean language” perspective. It irks me Smile.

About using $ to start symbols or omitting the 0-prefix for literals with H suffix, I disallow that to prevent the programmer from shooting himself in the foot. If you would e.g. define a symbol $face or Bah, on use it could be interpreted either as an integer literal, or shadow an integer literal, both undesirable. The third and only sane option would be to throw an error on definition of such a symbol (hm, sounds familiar). To the user the condition to trigger that error would be quite confusing (“Because your symbol matched the \$[0-9a-fA-F]+ production”). The grammar for labels would turn quite ugly.

Better to just disallow the entire class of $-prefix symbols. It’s not like it is generally supported by other assemblers or in general use, so I don’t need to do it for compatibility’s sake. The underlying (bad) thought was that I could maybe use it as an extension point for some built-in functions without conflicting with user symbols (e.g. “$size nop”). But it’s probably better to have a “glass” namespace and some kind of import statement anyway.

Basically, “that it can be done” doesn’t mean that “it should be done” :).

By spacemoai1973

Master (165)

spacemoai1973's picture

17-02-2020, 02:18

Interesting that you say $-prefix is not "generally supported by other assemblers or in general use", because entire industries are based on the $-prefix notation. Such that Metalion posted earlier that he had not even encountered any other notation before. (Actually your words make perfect sense when referring to #-prefix)

Labels shadowing literals is in my opinion an empowering feature and not something anyone needs to be protected against. In fact, case-sensitivity is a much more likely way for someone to shoot themselves in the foot with.

By santiontanon

Paladin (963)

santiontanon's picture

17-02-2020, 03:45

I'm not sure I agree there. Shadowing literals sounds very dangerous to me! What if after defined the label $face, you actually want to use $face as a number constant somewhere, and the compiler just gives you no warning. There is literally no way to see the error by looking at your assembler source file, unless you look at the generated machine code. This is really bad in my opinion... So, I only see two solutions that are acceptable in my mind: disallowing $-prefix symbols altogether, or at least disallowing those that conflict with names that could be literals.

By Wlcracks

Champion (421)

Wlcracks's picture

17-02-2020, 07:28

Going back to stuff you really need i think, because macro's are available in glass..
It would be awesome if glass could handle mega-roms.
So that its possible to include data files that overlay the megarom mapper pages in one go, and its possible to include data without the 64kb limit. Only thing you had to do manually is handle ingame is prepare the two megarom mapper pages.
Now i have to divide and or calculate that compressed data files fit into memorymapper pages, very inefficient. Why not one big output megarom file? I am not a pc software developer at all, but looks to me its just removing the limit of 64kb.

Also printing and calculating labels like the warning command works, but something like print "label:" label*40+1 would improve reporting whats going on. This would be a luxury feature. Now i use findstr in windows but you cannot calculate with that instruction. To report and calculate with equ labels is not possible because they are not included in the .sym file.

By Grauw

Ascended (9072)

Grauw's picture

17-02-2020, 10:09

spacemoai1973 wrote:

Interesting that you say $-prefix is not "generally supported by other assemblers or in general use", because entire industries are based on the $-prefix notation. Such that Metalion posted earlier that he had not even encountered any other notation before. (Actually your words make perfect sense when referring to #-prefix)

You misunderstood me, I support $ prefix integer literals, but disallow $ as a starting character for symbols. Starting H suffix integer literals with a decimal is also mandatory. Afaik that matches what most other assemblers do, hence general.

You think # is uncommon? I used it in Gen80 and Compass, but maybe I was one of the few.

About symbols shadowing literals being empowering, I see where you're coming from and I definitely see the benefits when applying the same principles to e.g. register literals (that's why it sounded familiar). But for integer literals I think it is better to keep them distinct.

Wlcracks wrote:

Now i have to divide and or calculate that compressed data files fit into memorymapper pages, very inefficient. Why not one big output megarom file? I am not a pc software developer at all, but looks to me its just removing the limit of 64kb.

Also to report and calculate with equ labels is not possible because they are not included in the .sym file.

Yes, that limit was a bad idea (it was intended to be helpful but it was not). I already removed it and if you get a development build it is no longer there.

I am also working on some other improvements so expect some additional updates in the near future. Including equ values in symbol files is one of them.

By spacemoai1973

Master (165)

spacemoai1973's picture

18-02-2020, 01:01

Grauw wrote:

You misunderstood me, I support $ prefix integer literals, but disallow $ as a starting character for symbols.

Ah, in that case indeed I did. That solution makes sense.

santiontanon wrote:

What if after defined the label $face, you actually want to use $face as a number constant somewhere, and the compiler just gives you no warning.

I think even a beginner assembly programmer is more than capable of being aware of what symbols and hex style he uses. It's about choice and empowerment. If you like symbols starting with $ you can still safely use any of the other supported hex styles. Otherwise you deal with the fact that some $symbol names cannot be from a very limited set of words that alias hex numbers. Or you decide not to use $symbol names. tniASM doesn't always hold your hand, but it will provide the greatest amount of flexibility with the least amount of complexity.

By Wlcracks

Champion (421)

Wlcracks's picture

18-02-2020, 07:27

Quote:

Yes, that limit was a bad idea (it was intended to be helpful but it was not). I already removed it and if you get a development build it is no longer there.

I am also working on some other improvements so expect some additional updates in the near future. Including equ values in symbol files is one of them.

Cool thank you but ... call me stupid but i cannot find this development build on https://bitbucket.org/grauw/glass/src/default/
Please could you pass me a link?

By Grauw

Ascended (9072)

Grauw's picture

18-02-2020, 10:40

I put development builds here: http://www.grauw.nl/etc/msx/glass.jar

Soon I’ll make a project page on my website to replace BitBucket, and I’ll make sure to include a link to the development build there as well.

By Wlcracks

Champion (421)

Wlcracks's picture

19-02-2020, 07:12

Thank you, that would be great!

Page 12/16
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16