z80asm: labeled ORG questionable

[udo-munk]

I have some old code like this:

^LZ80-Assembler Release 1.11-dev Wed Oct 12 08:39:17 2022 Page 1 Source file: m1m.asm Title:

LOC OBJECT CODE LINE STMT SOURCE CODE 1 1 ORG 0 2 2 0000 00 3 3 NOP 0001 00 4 4 NOP 0002 21 06 00 5 5 LD HL,STACK 0005 76 6 6 HALT 7 7 8 8 STACK ORG 0800H 0800 9 9 DS 16 10 10 0810 11 11 END

This code assumes that STACK gets assigned the value ORGed, not the current address. This is why the assembler prohibited a label for ORG, so that the user was forced to formulate

    ORG 0800H

STACK: DS 16

The problem now is not detected anymore and wrong code is generated. Question is what do other assemblers in this case?

[udo-munk]

SLR's CP/M z80asm also does this:

Z80ASM SuperFast Relocating Macro Assembler Z80ASM 1.30 Page 1 M1M Z80

1         0000              ORG     0
2                   
3 0000  00                  NOP
4 0001  00                  NOP
5 0002  21 0006             LD      HL,STACK
6 0005  76                  HALT
7                   
8         0800      STACK:  ORG     0800H
9 0800    0010              DS      16

10
0 Error(s) Detected. 2064 Absolute Bytes. 1 Symbols Detected.

[udo-munk]

And same with M80:

    MACRO-80 3.44   09-Dec-81       PAGE    1

                                    .Z80
                                    ORG     0

0000' 00 NOP 0001' 00 NOP 0002' 21 0006' LD HL,STACK 0005' 76 HALT

0006' STACK: ORG 0800H 0800' DS 16

                                    END

[udo-munk]

I like it better when the user is forced to put a label before or after an ORG, to explicitly formulate what is intended.

[sneakywumpus]

OK. What about .PHASE and .DEPHASE?

[sneakywumpus]

Another question: Should the listing contain an address for pseudo-ops which use AD_NONE but have a label? And lines that only have a label, which currently doesn't show an address?

[udo-munk]

.PHASE and .DEPHASE same as ORG change the current address. One can put labels in the line before and after, then it is clear what is intended. A label on the same line is questionable and it looks like when implemented it was done different. Finding a bug was difficult because assemblers handled this different, much easier to figure if this produces an error.

[udo-munk]

Labels or AD_NONE can show the address on the line if it can be implemnted without too much efforts. I never bothered about this because if not the next line generating code will show the address.

[ratboy666]

Check out R.MAC at

https://github.com/ratboy666/r

R.COM comes from the TOPS-10 R command -- run a commonly used system program (CUSP). For example:

R AID

to call up the AID processor (a BASIC-like language on the PDP-10).

R looks at A0: for the program, if not found, looks in A0:COMMAND.LBR

R.MAC uses .PHASE to start assembling the high memory part of the loader to location 0. It will be relocated.  To avoid a separate relocation pass, it could be phased to 0FD00H. Since there are NO opcodes in 8080 that are 0FDH, and we keep the code to a single page, if there is no 0FDH data in the page (can inspect the assembly output), we could then simply replace any 0FDH bytes with the target page during movement of the code.

I started with this implementation, but changed it to a separate relocation table (simpler to understand for publication). Still, this is the last use of .PHASE/.DEPHASE I have. The main reason for not using the 0FDH relocation trick is that the $$MOV procedure is used to move an open FCB. We cannot guarantee that the open FCB does not contain 0FDH bytes. So, use two $$MOV procedures, or take the 18 or so byte hit for supporting the relocation table -- I had coded both, and used the separate relocation table.

Not many people will use .PHASE -- when it is needed, it can be very useful. I left it in the R.MAC project, as it cleanly marks the relocated code.

FredW

On Wed, 2022-10-12 at 10:13 -0700, sneakywumpus wrote:

OK. What about .PHASE and .DEPHASE? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <udo- @.***>

[ratboy666]

If you look at my code in R.MAC, you will note that it does:

LOADER:      .PHASE 0 IPL:

This is because code with .PHASE usually need both labels! I do not think I have EVER put a label on a .PHASE line. Also, "back in the day" we did absolute assembly and argued for bytes. We then did a file that contains:

    ORG some_address label:    ORG label+bytes label2:

etc. Using absolute addresses, or label+offset . This "file" (we used the Intel assembler then) was passed in during PASS 1 of the assembly, followed by the actual code.

Of important, we did NOT (and I never have), put a label on an ORG line -- that practice would make my skin crawl.

If I had to move really old code like that forward, I would do something like

IF1     INCLUDE LAYOUT.INC ENDIF

(we can no longer present separate sources in PASS 1 and PASS 2, except for this bodge).

If there is a label on ORG, .PHASE, .DEPHASE, I would raise a "Questionable Syntax" warning, along with whatever the most convenient behaviour is. I would also (sort of) expect that LABEL: -- the : will register the next location to be assembled. I would expect that

LABEL: ORG 8000H

to be the same as LABEL:     ORG 8000H

Without the :? Don't know -- Only EQU, SET and MACRO as far as I know... The question is, what about

LABEL1:  LABEL2 EQU 3

is never really expected, but can be interpreted as

LABEL1: LABEL2 EQU 3

Can be allowed, but I would also issue Questionable syntax warning on the construction, even if it worked...

FedW

On Wed, 2022-10-12 at 10:48 -0700, udo-munk wrote:

.PHASE and .DEPHASE same as ORG change the current address. One can put labels in the line before and after, then it is clear what is intended. A label on the same line is questionable and it looks like when implemented it was done different. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <udo- @.***>

[ratboy666]

Just to make you laugh...

Of course, M80 is even stranger than all the others...

DB is (usually) not needed

1 2,3 4,5 (LXI H) 0,0

assembles just fine with M80 -- the rules of operation field are: MACRO, OPCODE, expression (in that order). And, of course (LXI H) is a fine expression. Not even questionable syntax on that one?!

FredW

On Wed, 2022-10-12 at 10:50 -0700, udo-munk wrote:

Labels or AD_NONE can show the address on the line if it can be implemnted without too much efforts. I never bothered about this because if not the next line generating code will show the address. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <udo- @.***>

[udo-munk]

If you look at the manuals of the old assemblers, like that from Intel, a label before ORG is not allowed and results in an error:

8080 MACRO ASSEMBLER, VER 3.0 ERRORS = 0

• 20:55 10/12/2022

• PAGE 1

  0000 ORG 0 0000 00 NOP 0001 00 NOP 0002 00 NOP Q 0800 010000 TEST ORG 0800H 0803 76 HLT 0804 76 HLT END 1 PROGRAM ERROR

[sneakywumpus]

Implemented in #167

[ratboy666]

Ok wow..

The Q (Questionable Syntax) comes up... can be considered a warning (do not do that).

Can you try

TEST: ORG 0800H

That may also be Q, or simply define TEST to be 0003. I dunno.

FredW

On Wed, 2022-10-12 at 11:57 -0700, udo-munk wrote:

If you look at the manuals of the old assemblers, like that from Intel, a label before ORG is not allowed and results in an error: 8080 MACRO ASSEMBLER, VER 3.0 ERRORS = 0

• 20:55 10/12/2022
• PAGE 1 0000 ORG 0 0000 00 NOP 0001 00 NOP 0002 00 NOP Q 0800 010000 TEST ORG 0800H 0803 76 HLT 0804 76 HLT END 1 PROGRAM ERROR — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: <udo- @.***>

[udo-munk]

With the : it is accepted.

0000 ORG 0 0000 00 NOP 0001 210500 LXI H,TEST 0004 00 NOP 0800 TEST: ORG 0800H 0800 76 HLT 0801 76 HLT END NO PROGRAM ERRORS