Hey Ramones, hmm really, interesting. From old (non-scene) assembler documentation and books that I read I had the impression that they all used to use xxH syntax, and some assemblers (M80? can’t be bothered to look it up) didn’t support #.
Yes, this is a hypothesis:
# Zilog syntax.
0xh Intel syntax.
$ Motorola syntax.
M80, remember, supports 8080 Intel cpu. Maybe this is the reason. However, Devpac GEN80 supports # and %.
But I’ll take your word for it that there has never been as uniform a notation as I thought there was. I guess I won’t change the notation on the MAP anytime soon, it’s just syntax in the end, though it’d be nice to be consistent.
Let's see: Is your site, your rules, of course. And... is your assembler. You can support or don't support several syntax.
Glass should also support the traditional syntax fully I hope, let me know if you feel that anything in particular is missing.
I should, to answer your question, try the glassZ80 assembler. And now I'm a bit busy. I'll try next week (i hope).
I try to also at least cover the commonly supported syntax, that’s why I added # and % support. I don’t really care for $ for hex though, or [] instead of ()… Especially in the case of [], I want to use it for sequence indexing in expressions once I get around to implementing that, so it would make expression parsing a lot more difficult if I would also allow it for indicating indirect addressing.
As I said, is your assembler. I know I'm a bit special with the assembler syntax nowadays. My first assembler programs, I used always lowercase and "Intel" syntax. Now I'm a bit "radical" with that and you can see a portion of code:
- SCRMOD -------------- - SET SCREEN MODE - HL: MODE DATA - SCRMOD LD DE,RG0SAV LD BC,#0880 $LOOP LD A,(HL) OUT (VDPCTRL),A LD (DE),A INC HL INC DE LD A,C OUT (VDPCTRL),A INC C DJNZ $LOOP - INIT VRAM -> 0 LD HL,#0000 LD BC,#4000 XOR A CALL FILVRM ....
- I don't use ; or :
- Traditional "Zilog" syntax
- Max 8 chars per label
- Sublabels with $ nor .
- Uppercase!!!!
- Comments with - or *
So... I know: I'm a bit special. Hence I have a python script to "preprocess" my source code to "whatever" cross-assembler (in this case, sjASM).
Really one feature I miss in *all* new cross-assembler is .REL files and linker. I know, this sound like a something of the past, but even nowadays is very useful. I'm working with other developer in a project and we never share our source code. To mix the parts of code we need a fixed address, size, etc... With a .REL file and .INC file (with PUBLIC labels/address) and a linker the problem would be fixed.
M80, AS.COM (Solid) and GEN80 support .REL and linker. I love PUBLIC/PRIVATE modules in my sources. sjASM has a "semi" support of modules (using sub labels).
So, support MODULES, would be welcome. ^^ (and linker and .REL file would be awesome!!!).
I would like to see it not use java
I chose Java because it is cross-platform , and also because I’m familiar with it. What’s your problem with it? You don’t want to install Java on your system? Now that they’re phasing out the browser plugin, there shouldn’t be any security issues with it anymore…
I was considering porting it to C#, but it’d just be too much effort for a bit of syntactic pleasure (Linq is really nice though). Also not many people on non-Windows systems have the .NET or Mono runtime installed on their computer, so I’d have to use the tools to compile to native code and those are not free and open source I think, although I haven’t looked into it deeply. Either way, it’s a bit too drastic of a change to change the language at this point in development.
Manuel just pointed me to gcj, which compiles Java bytecode to native code, maybe it’s worth investigating if there’s demand for it. If I’m lucky it’ll be really easy to integrate in the Maven build system.
I know I'm a bit special with the assembler syntax nowadays. My first assembler programs, I used always lowercase and "Intel" syntax. Now I'm a bit "radical" with that and you can see a portion of code:
[…]
- I don't use ; or :
- Comments with - or *
[…]
So... I know: I'm a bit special. Hence I have a python script to "preprocess" my source code to "whatever" cross-assembler (in this case, sjASM).
Ha, that is quite outlandish indeed . Reminds me of VHDL. I don’t think I would like to support it though, it makes expression parsing more difficult as - and * are also operators, and it’s not exactly commonly used. But the preprocessing script sounds like a good approach to implement your personal preferences like that.
- Sublabels with $ nor .
Well, there’s an interesting topic. Currently I’ve implemented scoping with the PROC directive, inspired by Pasmo, which establishes a local scope (just like MACRO btw).
However using labels prefixed with . as local labels is quite common syntax in modern Z80 assemblers, so I am considering to support it, I can see the appeal although I personally lean more towards preferring explicit scoping myself.
I could implement it so that labels not prefixed with . introduce an implicit scope, however it requires some refactoring, so I haven’t gotten to the point yet where it’s easy to add. But I want to do that refactor for other reasons as well so once that’s done I’m definitely considering it.
I do have plans for PROC too though, to make it more like a macro with arguments and automatically generate variations of the method (so I can easily make ix and iy versions of functions by just specifying at the call site which one I want), so that’s the practical benefit of PROC that I have in mind.
Really one feature I miss in *all* new cross-assembler is .REL files and linker. I know, this sound like a something of the past, but even nowadays is very useful. I'm working with other developer in a project and we never share our source code. To mix the parts of code we need a fixed address, size, etc... With a .REL file and .INC file (with PUBLIC labels/address) and a linker the problem would be fixed.
M80, AS.COM (Solid) and GEN80 support .REL and linker. I love PUBLIC/PRIVATE modules in my sources. sjASM has a "semi" support of modules (using sub labels).
So, support MODULES, would be welcome. ^^ (and linker and .REL file would be awesome!!!).
Also a very interesting topic. Currently Glass can generate a symbol file (I use it a lot for debugging in openMSX ), but there is no ability to specify labels as public or not. I need to work out what the requirements and best syntax for it would be. If you have any particular examples of a well-done modules implementation (doesn’t need to be assembler), it’d be interesting to use as brainstorm material.
As for REL files, I agree they are useful and it has crossed my mind, but they’re also a topic I don’t know much about or that I’ve personally needed, so it’s not been a goal of mine to implement. I worry a bit about limitations the format might impose, e.g. how it handles alignment etc (I guess ds 8000H - $ and such are not supported, it probably relies on directives if it can do it at all?). Either way, I need to read up on it, that much is clear.
Given that MSX originated from Microsoft and M80 being the official assembler, I fully support Grauw's decision to go with the M80 notation.
But the whole discussion is reminiscent of "You Say Potatoe, I Say Potato".
Well it’s not a decision… just for me it feels like the “primary Z80 notation”. At least the current Z80 manual also uses it. Anyway in Glass since version 0.4 I support both, it wasn’t a problem to parse and if users want to use the other notation or if it helps to compile sources originally written for other assemblers, that’s totally cool. On the MAP I’ll just leave things as they are, it’s the easiest course of action hehe .
As for REL files, I agree they are useful and it has crossed my mind, but they’re also a topic I don’t know much about or that I’ve personally needed, so it’s not been a goal of mine to implement. I worry a bit about limitations the format might impose, e.g. how it handles alignment etc (I guess ds 8000H - $ and such are not supported, it probably relies on directives if it can do it at all?). Either way, I need to read up on it, that much is clear.
Rel files and areas are essential elements of assemblers. What happened was most assemblers written for the z80 home computers in the 1980s were written for limited machines where disk drives were not standard. So the assemblers were simplified, dropping linking features. Unfortunately the new batch of z80 cross assemblers that appeared over the last couple of decades were written by people familiar with these simplified assemblers and unfamiliar with how assembling and linking works on "real" machines.
For the z80 there are a limited number of cross assemblers that are modern in this sense. AFAIK the list is: asz80 (sdcc uses it), z80asm (z88dk uses it -- there is another assembler named z80asm that is distributed independently of z88dk; this assembler is not the same one and is much simpler), vasm (associated with a C compiler that does not currently have a z80 target) and zmac.
It's not surprising that C compilers would be using assemblers with linking capability as C compilers are built around sharing code -- they have very large libraries of subroutines that cannot all be in the output binary at once -- there wouldn't be room for it all.
The area/section capability is a means for the assembler to generate memory maps so that you can output generated code and data to specific memory addresses or memory banks.
Pasmo and sjasm have tried to make up for missing linking and area capability by supplying adhoc features like procs and specialized targets (128k spectrum in sjasmplus) but it's much better to do it properly
This is my current line of thinking:
https://bitbucket.org/grauw/glass/issue/1/define-fields-with...
Seems like a nice idea, right?
Ok, I'll do some grave digging here... I don't know if we are talking exactly same issue, but I would like to write something like this:
org #5000 RAM equ #C000 ld a,3 ld hl,0 ld (lives),a ld (points),hl nosave RAM lives: nop points: dw 0 end nosave xor a ld (extras),a nosave ; Parameter not defined, so points to last address = #C003 exras: db 0 end nosave ret
Ok... Yet another format not commonly supported, but might be handy to use.
On the good side would be that you could move part of the variables to RAM easily to make ROM-version even if you have done "RAM only" version first...
@Alcoholics_Anonymous Thanks for you elaboration .
@NYYRIKKI I think that’s what SECTION and DS VIRTUAL achieve, with a slightly different syntax.
On another note, since the ENDM directive is used to terminate REPT and IRP in z80asm, asz80, zmac, Pasmo and M80, I’ve reverted that change which introduced ENDR.
a) In the following code:
c: equ 10H ld a,c
What do you expect the output to be?
- ld a,10
- ld a,c
- error
- something else
b) In the following code:
ld_a_index: MACRO ix, offset ld a,(ix + offset) ENDM ld_a_index iy, 10
What do you expect the output to be?
- ld a,(iy + 10)
- ld a,(ix + 10)
- error
- something else
c) In the following code:
x: db 0 y: db 0 z: db 0 ClearZ: ld hl,z ld (hl),0 ret
What do you expect the result of calling ClearZ to be?
- the z byte is set to 0
- error at the ld hl,z
- error at the z: label
- something else
What do you expect the output to be?
What do I expect or what would I like to happen?
With Sjasm I expect ld a,c, ld a,(iy + 10) and probably an error at ld hl,z. But of course it wasn't a smart move to allow labels with the same name as instructions or worse, the same name as registers.
nosave RAM lives: nop points: dw 0 end nosave
Here I would like to see an errormessage because the RAM won't be initialised.