Devpac: Data section in Chip-Mem

This is my first post, so bear with me...

My Devpac3 documenation suggests that I can get data-sections loaded in Chip-mem with this assembler directive before the data:

SECTION Image,DATA_C

But how is this supposed to work in practice? The code is relocatable, and is loaded somewhere in Fast-Mem, $200000-somewhere on my system. In my code I'm referencing relative symbols, how am I supposed to reach the data if the AmigaDOS-loader puts a section/hunk somewhere in Chip-Mem?

My workaround now is to allocate chip-mem and move the data at runtime.

Any thoughts or input around this?

Kind regards,
R. Bratseth

[ross]

Hi and welcome.

There are two methods.
- advanced: scan through hunks list in memory
- standard an simple that use reloc in executable: reference through a label

For the latter one example is:

SECTION Code,CODE
Start: lea my_image,a0
       ...
       rts

SECTION Image,DATA_C
my_image: ds.b 320*256/8

[Galahad/FLT]

Originally Posted by roger_bratseth

This is my first post, so bear with me...

My Devpac3 documenation suggests that I can get data-sections loaded in Chip-mem with this assembler directive before the data:

SECTION Image,DATA_C

But how is this supposed to work in practice? The code is relocatable, and is loaded somewhere in Fast-Mem, $200000-somewhere on my system. In my code I'm referencing relative symbols, how am I supposed to reach the data if the AmigaDOS-loader puts a section/hunk somewhere in Chip-Mem?

My workaround now is to allocate chip-mem and move the data at runtime.

Any thoughts or input around this?

Kind regards,
R. Bratseth

Because of the potential distance between sections, and the fact you're using sections, you won't be able to use PC relative code to reference data in other areas of memory.

You will have to use absolute addresses, which will relocate to the correct address when the program is run.

If you wish to keep your code PC relative and use pointers, that keeps your code neat.

So for instance

move.l picture_pointer(pc),a0

picture_pointer: dc.l picture

Section Picture,Data_C
Picture: incbin sysicture.raw

But most will settle for simply using absolute which will relocate.

lea picture,a0

[ross]

Just to add some info about "indirect" access suggested by Galahad (that I make it also fall into the second of my cases).

You might ask why use a slower code (four more cycles, [EDIT:in pure 68k]), which requires 2 bytes more in code section and that in any case uses a relocation.
Well, to maintain open a possibility for a change of "picture_pointer" in successive code. You can take the first setup like an init.

If you think you never change the pointer then use the lea statement.

[phx]

Originally Posted by Galahad/FLT

Because of the potential distance between sections, and the fact you're using sections, you won't be able to use PC relative code to reference data in other areas of memory.

Nearly unknown to most people is that OS3.0 introduced a new relocation hunk called HUNK_RELRELOC32, which in fact enables resolving relative references between sections! It only works with 32-bit PC-relative references though, so a 68020 is required, additionally to V39.

[meynaf]

Personnally I value the BASEREG directive very much. Ok, it doesn't work on Devpac

[ross]

Originally Posted by phx

Nearly unknown to most people is that OS3.0 introduced a new relocation hunk called HUNK_RELRELOC32, which in fact enables resolving relative references between sections! It only works with 32-bit PC-relative references though, so a 68020 is required, additionally to V39.

Never interested (but I had seen him in the list of available) at this hunk.
Can be useful to make more compact 020+ code (freeing some structured data).
Thank you for highlighting its existence

Originally Posted by meynaf

Personnally I value the BASEREG directive very much. Ok, it doesn't work on Devpac

Yes, BASEREG register usage are really valuable and a good practice! (I've always used it "manually" in Devpac for the heap).