"BSS" with ORG'ed code

[paraj]

Is there a way to do the moral equivalent of ds.y/dx.y without increasing the section size?
Concretely I'm making an executable that kills the system and relocates itself at a specific address, and don't want to unnecessarily increase the section size. (See below code).
I'd like to just do "somvar1 ds.l 1" (or similar) rather than my hack of trying to guess the code size (rsset needs a constant expression).
Using vasm, but isn't (wasn't) this a common "issue"? Hope the question makes sense

LOAD_ADDR=$8000

        SECTION code,code    
start:
        move.w  #$7fff,d0
        move.w  d0,$dff09a
        move.w  d0,$dff09c

        lea     code_start(pc),a0
        lea     .reloc(pc),a1
        move.w  #$20,a2
        moveq   #(.reloc_end-.reloc)/2-1,d0
.reloc0:
        move.w  (a1)+,(a2)+
        dbf     d0,.reloc0
        jmp     $20.w

.reloc:
        lea     LOAD_ADDR,a1
        move.l  #(code_end+3-main)/4,d0
        cmpa.l  a0,a1
        bls.b   .copy_down
        move.l  d0,d1
        lsl.l   #2,d1
        add.l   d1,a0
        add.l   d1,a1
.copy_up:
        move.l  -(a0),-(a1)
        subq.l  #1,d0
        bne.b   .copy_up
        jmp     LOAD_ADDR
.copy_down:
        move.l  (a0)+,(a1)+
        subq.l  #1,d0
        bne.b   .copy_down
        jmp     LOAD_ADDR
.reloc_end:

code_start:
        ORG LOAD_ADDR

main:
        move.l  #42,somevar1
        move.l  #666,somevar2
        bra     main

code_end=*


CODE_SIZE=$4000
        if code_end-main>CODE_SIZE
        error increase CODE_SIZE
        endc

        rsset LOAD_ADDR+CODE_SIZE
somevar1 rs.l 1
somevar2 rs.l 1 ; Imagine this is rs.w 40000 or whatever

[phx]

Originally Posted by paraj

Is there a way to do the moral equivalent of ds.y/dx.y without increasing the section size?

The common method to do that would be something like:

        *=*+4

or even combined:

myvar: *=*+4

Although, this was mostly common in absolute 8-bit code and vasm's

oldstyle

syntax module supports it perfectly. But I didn't see that a lot in Motorola's 68k syntax, where '

*

' often introduces a comment.

I'd like to just do "somvar1 ds.l 1" (or similar) rather than my hack of trying to guess the code size

The "modern" approach to realize uninitialized sections in an absolute program, while making them not part of the final binary, would be the task of a proper linker-script, using the

NOLOAD

keyword for that section.

That said, you can indeed achieve similar behaviour like

*=*+n

with vasm's mot-syntax module, but I'm not sure how compatible it is with other assemblers. When there are better, more portable solutions, I am happy to implement them. This works:

somevar1 org *+4

So you could try to modify your code like this:

LOAD_ADDR=$8000

        SECTION code,code    
start:
        move.w  #$7fff,d0
        move.w  d0,$dff09a
        move.w  d0,$dff09c

        lea     code_start(pc),a0
        lea     .reloc(pc),a1
        move.w  .dest,a2
        moveq   #(.reloc_end-.reloc)/2-1,d0
.reloc0:
        move.w  (a1)+,(a2)+
        dbf     d0,.reloc0
        jmp     .dest.w

.reloc:
        org     $20
.dest:
        lea     LOAD_ADDR,a1
        move.l  #(code_end+3-main)/4,d0
        cmpa.l  a0,a1
        bls.b   .copy_down
        move.l  d0,d1
        lsl.l   #2,d1
        add.l   d1,a0
        add.l   d1,a1
.copy_up:
        move.l  -(a0),-(a1)
        subq.l  #1,d0
        bne.b   .copy_up
        jmp     LOAD_ADDR
.copy_down:
        move.l  (a0)+,(a1)+
        subq.l  #1,d0
        bne.b   .copy_down
        jmp     LOAD_ADDR
        section code,code
.reloc_end:

code_start:
        ORG LOAD_ADDR

main:
        move.l  #42,somevar1
        move.l  #666,somevar2
        bra     main

code_end=*

somevar1        org     *+4
somevar2        org     *+4

[hooverphonique]

I think

move.w  .dest,a2

should be

move.w  #.dest,a2

[phx]

Correct! I inserted the

org $20

and

.dest

to make it more readable, where I did that typo.

Probably paraj was aware of it, but I should mention that an

org

inside of a normal section, like in this example, is handled different as if you start your code directly with an

org

. Here the code after

org

is still part of the

code

section. But all its labels are relocated to an absolute address. You can switch back to the normal section with a

section

directive.

A noticeable difference is that there is no gap in the code between these relocated org blocks, which you would otherwise get in real absolute output without a

section

directive.

[paraj]

Thanks for the feedback! Forgot to mention in my post that I had already seen stuff like

somevar1=*
somvar2=somvar1+4
somvar3=somvar2+16

in other code, which I find "unacceptable" as it's too hard to maintain (changing order is tedious and the object size is in the wrong place).

somevar1 org *+4

works and is OK! rs.y/ds.y is a bit more readable, but nothing too bad.

The "modern" approach to realize uninitialized sections in an absolute program, while making them not part of the final binary, would be the task of a proper linker-script, using the NOLOAD keyword for that section.

Yeah, but then I would need two files and perhaps a slightly more complicated build process (good to keep in mind though, and definitely the way to go if this gets more advanced).

Had another look at the vasm manual, and on a hunch I tried

__RS set *

and it work perfectly!
In asm-pro (1.19c, i.e. one of a/b's recent builds) that doesn't work, but

rsset *

seems to do the same.

Maybe there's something I'm missing, but maybe the restriction on the argument to rsset could be lifted without issue?

I.e.

	section code,code
	move.l	#var1,d0
	move.l	#var2,d1
	move.l	#var3,d2
	rts
	ORG $1000
	rsset * ; if VASM use "__RS set *"
var1:	rs.l	4
var2:	rs.w	$1000
var3:	rs.l	0

should produce a 56 byte executable with code:

        MOVE.L  #$00001000,D0
        MOVE.L  #$00001010,D1
        MOVE.L  #$00003010,D2
        RTS

[phx]

Originally Posted by paraj

somevar1 org *+4

works and is OK! rs.y/ds.y is a bit more readable, but nothing too bad.

You can always define a macro. For example

du.x

for declare uninitialized space:

du      macro
        ifc     '\0','b'
        org     *+\1
        endc
        ifc     '\0','w'
        org     *+2*\1
        endc
        ifc     '\0','l'
        org     *+4*\1
        endc
        endm

Had another look at the vasm manual, and on a hunch I tried

__RS set *

and it work perfectly!
In asm-pro (1.19c, i.e. one of a/b's recent builds) that doesn't work, but

rsset *

seems to do the same.

Ok. That's good. I checked Devpac and it accepts that too, but then the RS-counter seems to be stuck on the initial address and doesn't advance anymore.

Maybe there's something I'm missing, but maybe the restriction on the argument to rsset could be lifted without issue?

Either that, or the

__RS set *

is a bug. So I checked the source again, and indeed, the restriction was never needed. It even works within a relocatable section. Patch is committed and available with tomorrow's snapshot. Thanks!

--- syntax/mot/syntax.c 10 May 2023 10:08:58 -0000      1.237
+++ syntax/mot/syntax.c 24 May 2023 08:44:33 -0000      1.238
@@ -1483,7 +1483,7 @@
 
 static void handle_rsset(char *s)
 {
-  new_abs(rs_name,number_expr(parse_constexpr(&s)));
+  new_abs(rs_name,parse_expr_tmplab(&s));
 }
 
 static void handle_rseven(char *s)
@@ -1498,7 +1498,7 @@
 
 static void handle_setfo(char *s)
 {
-  new_abs(fo_name,number_expr(parse_constexpr(&s)));
+  new_abs(fo_name,parse_expr_tmplab(&s));
 }
 
 static void handle_rs8(char *s)

[Photon]

I'm thinking you're trying to write your own code to do things that there are already options for? Is it possible that you misunderstand ORG, LOAD, etc? (If not just try to explain the goal/what you're trying to achieve.)

If the absaddr code is not PC-relative, you have to put system off code at the start of it and reset every time you test it, unless the address is in available memory. Then you can ORG and LOAD and define a JUMPPTR. Outside an IDE it's just a pure binary file, and there's no monitor inside Amiga OS to jump to an address.

One problem might be that you have to write an executable file every time you want to run it? Amiga OS won't load it to the right address, so you are trying to do what execrunchers do (without the crunching).

Nevertheless, this was how it was done before RAM expansions on A500 etc, to allow the binary to be started from the OS, still able to use almost all of the chipmem, and not require the RAM expansion, and not require an entire disk for one program.

If this is to be part of a devchain, then perhaps include an execruncher in it and done? Or include a trackloader and write a disk image instead of an exe file. (Since absolute addressing might require a reboot on every run anyway.)

There's nothing really to stop an IDE or a normal text editor (if native) to compile by calling a command-line compiler. Those editors can include a monitor that can not only jump to the right address.

The AsmOne etc. assemblers do this and support ORG/LOAD, just ORG to declare ds, and mix ORG/LOAD with SECTIONs. An alternative is to make such an assembler the last part of a devchain. The "assemble this source and and run it" can be provided as a command line parameter.

If you want to provide a single structure to declare lots of offsets (e.g. buffers or structures), many assemblers support this with directives.

If you want to make calculations between symbols and get an error out of it, this depends on how many passes the assembler is using. It's normal to do a first pass to establish the values of all symbols (so that the order in which you write your code is not forced, e.g. forward references).

If you try to do the calculation before all symbols have values, you should get an error to that effect in every Assembler.

In AsmOne etc. you can wrap such checks in the "IF2" directive to make sure the check is ignored in pass 1.

[paraj]

It even works within a relocatable section. Patch is committed and available with tomorrow's snapshot. Thanks!

Applied above patch to snapshot from last night, and it works as expected, thanks! Not sure how useful it is in relocatable sections, but good that it works

I'm thinking you're trying to write your own code to do things that there are already options for? Is it possible that you misunderstand ORG, LOAD, etc? (If not just try to explain the goal/what you're trying to achieve.)

Yes, it's very likely that I'm doing stupid stuff , but I'll try to explain.
This is strictly meant for 100% system killing code. Likely trackloaded, but could be done from an executable (like in my original post).
For my current experiments it's because I need to put some large tables in "low" memory (<$8000) for optimization purposes.
In a trackloaded scenario it's nice to have stuff in fixed (but flexible) memory locations with assembler help.

These days I use vasm and cross-compile (assemble) with WinUAE for most testing, and an executable is easier than creating an ADF with trackloader+code, and when I do test on my Amiga it's also easier: just transfer executable (even if I need to reboot afterwards).

If I were doing my development in e.g. Asm-Pro I'd try to do a more gentle system supspension, copy the first 64K somewhere else and restore them, etc.

[Photon]

It must be a very special case.

Yep, if you can restore low mem correctly, you can allow exit. This was sometimes done in the early years when RAM expansions came and "FastMemFirst" wasn't obeyed or not working 100%.