Mutable data in code section

hop · 07 June 2022, 22:57

Sorry if this is a dumb question, but is it safe to store state in the code section of an Amiga hunk executable?

Code:

SECTION	code
	<hardware code (copper/playfield/blitter>
	<code which updates xpos and ypos>
	rts

xpos		dc.w	0	
ypos		dc.w	0

	SECTION bss
	<etc>

I'm launching this as the first exe in the startup-sequence of an unexpanded A500 1.3 in WinUAE. The first time I can see that xpos and ypos are zero in the debugger on launch.

When the exe quits I launch it again (t/exe) and I can see that xpos and ypos are NOT zero. I'm not sure if the values are just whatever is in their current address.

If I move the data to the bss section all is well, but obviously BSS sections are cleared on launch.

I know that it's probably not good practice to store state in with code due to 020 CPU caches and best practices, but I thought in this case it would work.

ross · 07 June 2022, 23:24

Quote:

Originally Posted by hop

is it safe to store state in the code section of an Amiga hunk executable?

Yes.

Quote:

The first time I can see that xpos and ypos are zero in the debugger on launch.

When the exe quits I launch it again (t/exe) and I can see that xpos and ypos are NOT zero. I'm not sure if the values are just whatever is in their current address.

This is not possible. 'state' variables are static, and bytes at 0 are inserted in the exe file.

The only possibility that comes to mind is that they are bss data entered as CODE_BSS in the hunk (like dx.w directive).
The CODE_BSS 'part' is not zeroed on KS1.X (it is on 2.0+).
Probably even the first time it was only by chance that it were already zero.

Quote:

I know that it's probably not good practice to store state in with code due to 020 CPU caches and best practices, but I thought in this case it would work.

It works on every processor of the 68k family, in any case they are considered as data and used by the caches as such.
Of course it would be theoretically better to put them in the DATA section due to possible protections by the MMU, but I don't think you will ever find situations where it doesn't work.

For example, I often make code that uses a single CODE hunk, which also contains DATA and BSS (that I manually clear at run-time, to be KS1.x compatible).

hop · 07 June 2022, 23:34

Thanks. It must be a memory stomp very early on in the code. I'll keep digging.

hop · 07 June 2022, 23:43

Attached executable. Go easy on me - I wrote this in the 90s and just fixed it up! Text routine works fine first launch, but not second time round.

a/b · 08 June 2022, 06:58

As already noted, the problem is code+bss hunk. Your first "code" hunk is $368 lwords allocated and $367 actual, meaning the last lword is bss, and is never initialized under KS1.x. The first time it happens to be a zero, so everything works ok.
You have to explicitely initialize that lword (x/y coord, right?) with your code, before using it, or tell the assembler to produce pure code hunk and alwalys include trailing zero data as part of it and not as bss (not sure why it's doing it, DC.W is *not* DS.W, and it shouldn't be handled as bss).

hop · 08 June 2022, 08:59

Thanks for the insight. This is a real gotcha! I had already implemented a workaround (manually initialise the values), but wasn't happy not understanding it - an accident waiting to happen. When I write

label dc.w 0

I would expect label to be zero by default, always.

I am building with vasm/vlink:

Code:

vasmm68k_mot -I%NDK%\Include_I -I%INCLUDE% -Fhunk -kick1hunks -no-opt -wfail -L intermediates\%name%.list -o intermediates\%name%.o %name%.s || exit /b 1
vlink -bamigahunk -L%NDK%\lib -lamiga -o %Build%\%name% intermediates\%name%.o || exit /b 1

Hunkdump for context:

Code:

Opened file: Typetro
File size: 111444 (0x1B354) bytes
0x0: HUNK_HEADER (0x3F3, 1011)
Table size: 5
First root hunk: 0
Last hunk: 4
Root hunk 0  Size: 872 (0x368) longwords (3488 (0xDA0) bytes)  Memory type: ANY  Address: 0x00100
Root hunk 1  Size: 3 (0x3) longwords (12 (0xC) bytes)  Memory type: ANY  Address: 0x00EC0
Root hunk 2  Size: 26413 (0x672D) longwords (105652 (0x19CB4) bytes)  Memory type: CHIP  Address: 0x00F00
Root hunk 3  Size: 0 (0x0) longwords (0 (0x0) bytes)  Memory type: ANY  Address: 0x1ABC0
Root hunk 4  Size: 10240 (0x2800) longwords (40960 (0xA000) bytes)  Memory type: CHIP  Address: 0x1ABC0

=== HUNK 0 ===

0x28: HUNK_CODE (0x3E9, 1001)
Code size: 871 (0x367) longwords (3484 (0xD9C) bytes)
0xDCC: HUNK_RELOC32 (0x3EC, 1004)
Offset count: 44
Hunk index: 0
Offset count: 18
Hunk index: 1
Offset count: 12
Hunk index: 2
Offset count: 5
Hunk index: 4
0xF30: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1554: HUNK_END  (0x3F2, 1010)

=== HUNK 1 ===

0x1558: HUNK_CODE (0x3E9, 1001)
Code size: 1 (0x1) longwords (4 (0x4) bytes)
0x1564: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x15B8: HUNK_END  (0x3F2, 1010)

=== HUNK 2 ===

0x15BC: HUNK_DATA (0x3EA, 1002)
Data size: 26413 (0x672D) longwords (105652 (0x19CB4) bytes)
0x1B278: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1B318: HUNK_END  (0x3F2, 1010)

=== HUNK 3 ===

0x1B31C: HUNK_DATA (0x3EA, 1002)
Data size: 0 (0x0) longwords (0 (0x0) bytes)
0x1B324: HUNK_END  (0x3F2, 1010)

=== HUNK 4 ===

0x1B328: HUNK_BSS (0x3EB, 1003)
BSS size: 10240 (0x2800) longwords (40960 (0xA000) bytes)
0x1B330: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1B350: HUNK_END  (0x3F2, 1010)

End of file.  Offset: 0x1B354

I've had a scan through the docs, but nothing is jumping out. I can't see a way to ensure that the first HUNK_CODE block is forced up from $367 to the root hunk (header) size of $368 bytes.

hooverphonique · 08 June 2022, 09:49

Quote:

Originally Posted by a/b

(not sure why it's doing it, DC.W is *not* DS.W, and it shouldn't be handled as bss).

Yes, that looks like a bug (or perhaps option) in the assembler/linker. dc.x is static data, not bss.

hop · 08 June 2022, 09:51

Short hunks are a new one to me. Thanks for making me aware of this. Found a couple of mentions of it in the Guru Book under InternalLoadSeg() and HUNK_HEADER.

Also found the vlink option:

Code:

-Z                keep trailing zero-bytes in executables

I can't see an equivalent vasm option.

Looking better now:

Code:

Opened file: Typetro
File size: 111456 (0x1B360) bytes
0x0: HUNK_HEADER (0x3F3, 1011)
Table size: 5
First root hunk: 0
Last hunk: 4
Root hunk 0  Size: 872 (0x368) longwords (3488 (0xDA0) bytes)  Memory type: ANY  Address: 0x00100
Root hunk 1  Size: 3 (0x3) longwords (12 (0xC) bytes)  Memory type: ANY  Address: 0x00EC0
Root hunk 2  Size: 26413 (0x672D) longwords (105652 (0x19CB4) bytes)  Memory type: CHIP  Address: 0x00F00
Root hunk 3  Size: 0 (0x0) longwords (0 (0x0) bytes)  Memory type: ANY  Address: 0x1ABC0
Root hunk 4  Size: 10240 (0x2800) longwords (40960 (0xA000) bytes)  Memory type: CHIP  Address: 0x1ABC0

=== HUNK 0 ===

0x28: HUNK_CODE (0x3E9, 1001)
Code size: 872 (0x368) longwords (3488 (0xDA0) bytes)
0xDD0: HUNK_RELOC32 (0x3EC, 1004)
Offset count: 44
Hunk index: 0
Offset count: 18
Hunk index: 1
Offset count: 12
Hunk index: 2
Offset count: 5
Hunk index: 4
0xF34: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1558: HUNK_END  (0x3F2, 1010)

=== HUNK 1 ===

0x155C: HUNK_CODE (0x3E9, 1001)
Code size: 3 (0x3) longwords (12 (0xC) bytes)
0x1570: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x15C4: HUNK_END  (0x3F2, 1010)

=== HUNK 2 ===

0x15C8: HUNK_DATA (0x3EA, 1002)
Data size: 26413 (0x672D) longwords (105652 (0x19CB4) bytes)
0x1B284: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1B324: HUNK_END  (0x3F2, 1010)

=== HUNK 3 ===

0x1B328: HUNK_DATA (0x3EA, 1002)
Data size: 0 (0x0) longwords (0 (0x0) bytes)
0x1B330: HUNK_END  (0x3F2, 1010)

=== HUNK 4 ===

0x1B334: HUNK_BSS (0x3EB, 1003)
BSS size: 10240 (0x2800) longwords (40960 (0xA000) bytes)
0x1B33C: Skipping HUNK_SYMBOL (0x3F0, 1008)
0x1B35C: HUNK_END  (0x3F2, 1010)

End of file.  Offset: 0x1B360

Guess I'll have to update all my build scripts, just in case, and also update my custom loaders to handle this in case it comes back to haunt me.

hop · 08 June 2022, 09:53

Quote:

Originally Posted by hooverphonique

Yes, that looks like a bug (or perhaps option) in the assembler/linker. dc.x is static data, not bss.

Perhaps. I can see why the vasm/vlink would trim unused zero bytes, but not those containing static data labels which is explicitly referenced.

phx · 08 June 2022, 11:52

Explanation: The default behaviour of vasm and vlink is to generate programs for AmigaOS2.0+. Which means that vlink will always remove trailing zero-bytes (which have no relocation attached), while vasm will always use short-relocs (HUNK_RELOC32SHORT).

Admittedly, this is quite stupid, because either both tools should use both features at all time, or none of them. But this is historical, and I cannot easily change that now.

TL;DR?
For Kickstart 1.x:
vasm: -kick1hunks
vlink: -Z (or initialise code-bss/data-bss yourself)

For OS2.0+:
vasm:
vlink: -Rshort (optional)

ross · 08 June 2022, 12:01

There is also a third way:
xpos dc.w 0
ypos dc.w 0
cpos dc.w 1

i.e. insert a non-zero data value as the last variable.
So you no longer have to worry about compiler / linker specific (default) options

hop · 08 June 2022, 12:17

Thanks very much.

Quote:

Originally Posted by phx

Explanation: The default behaviour of vasm and vlink is to generate programs for AmigaOS2.0+. Which means that vlink will always remove trailing zero-bytes (which have no relocation attached)

I might be wrong, but for the executable in question it looks like the last two (trimmed) longwords are indeed relocated. Here's another hunk dump/load-simulation of the executable, linked without -Z, and with relocated offsets shown:

Code:

Opened file: Typetro
File size: 111444 (0x1B354) bytes
0x0: HUNK_HEADER (0x3F3, 1011)
Table size: 5
First root hunk: 0
Last hunk: 4
Root hunk 0  Size: 872 (0x368) longwords (3488 (0xDA0) bytes)  Memory type: ANY  Address: 0x00100
Root hunk 1  Size: 3 (0x3) longwords (12 (0xC) bytes)  Memory type: ANY  Address: 0x00EC0
Root hunk 2  Size: 26413 (0x672D) longwords (105652 (0x19CB4) bytes)  Memory type: CHIP  Address: 0x00F00
Root hunk 3  Size: 0 (0x0) longwords (0 (0x0) bytes)  Memory type: ANY  Address: 0x1ABC0
Root hunk 4  Size: 10240 (0x2800) longwords (40960 (0xA000) bytes)  Memory type: CHIP  Address: 0x1ABC0

=== HUNK 0 ===

0x28: HUNK_CODE (0x3E9, 1001)
Code size: 871 (0x367) longwords (3484 (0xD9C) bytes)
0xDCC: HUNK_RELOC32 (0x3EC, 1004)
Offset count: 44
Hunk index: 0
  Offset 0: 14 (0xE) bytes.  Value: 0x00000608 -> 0x00000708
  Offset 1: 314 (0x13A) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 2: 320 (0x140) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 3: 342 (0x156) bytes.  Value: 0x00000B7E -> 0x00000C7E
  Offset 4: 358 (0x166) bytes.  Value: 0x00000B5E -> 0x00000C5E
  Offset 5: 376 (0x178) bytes.  Value: 0x0000054E -> 0x0000064E
  Offset 6: 384 (0x180) bytes.  Value: 0x000005E6 -> 0x000006E6
  Offset 7: 554 (0x22A) bytes.  Value: 0x00000B3E -> 0x00000C3E
  Offset 8: 948 (0x3B4) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 9: 954 (0x3BA) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 10: 972 (0x3CC) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 11: 980 (0x3D4) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 12: 992 (0x3E0) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 13: 1000 (0x3E8) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 14: 1008 (0x3F0) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 15: 1020 (0x3FC) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 16: 1068 (0x42C) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 17: 1078 (0x436) bytes.  Value: 0x00000B7E -> 0x00000C7E
  Offset 18: 1100 (0x44C) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 19: 1106 (0x452) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 20: 1124 (0x464) bytes.  Value: 0x00000D9C -> 0x00000E9C
  Offset 21: 1130 (0x46A) bytes.  Value: 0x00000D9E -> 0x00000E9E
  Offset 22: 1482 (0x5CA) bytes.  Value: 0x00000A4E -> 0x00000B4E
  Offset 23: 1488 (0x5D0) bytes.  Value: 0x00000A4A -> 0x00000B4A
  Offset 24: 1494 (0x5D6) bytes.  Value: 0x00000A54 -> 0x00000B54
  Offset 25: 1504 (0x5E0) bytes.  Value: 0x00000AD9 -> 0x00000BD9
  Offset 26: 1546 (0x60A) bytes.  Value: 0x00000A52 -> 0x00000B52
  Offset 27: 1554 (0x612) bytes.  Value: 0x00000A52 -> 0x00000B52
  Offset 28: 1562 (0x61A) bytes.  Value: 0x00000A52 -> 0x00000B52
  Offset 29: 1950 (0x79E) bytes.  Value: 0x00000A54 -> 0x00000B54
  Offset 30: 1956 (0x7A4) bytes.  Value: 0x00000ADA -> 0x00000BDA
  Offset 31: 2030 (0x7EE) bytes.  Value: 0x00000ADA -> 0x00000BDA
  Offset 32: 2164 (0x874) bytes.  Value: 0x00000A4A -> 0x00000B4A
  Offset 33: 2178 (0x882) bytes.  Value: 0x00000A4A -> 0x00000B4A
  Offset 34: 2184 (0x888) bytes.  Value: 0x00000A4E -> 0x00000B4E
  Offset 35: 2204 (0x89C) bytes.  Value: 0x00000A4E -> 0x00000B4E
  Offset 36: 2210 (0x8A2) bytes.  Value: 0x00000ADC -> 0x00000BDC
  Offset 37: 2218 (0x8AA) bytes.  Value: 0x00000ADC -> 0x00000BDC
  Offset 38: 2388 (0x954) bytes.  Value: 0x00000ADA -> 0x00000BDA
  Offset 39: 2442 (0x98A) bytes.  Value: 0x00000ADC -> 0x00000BDC
  Offset 40: 2456 (0x998) bytes.  Value: 0x00000A4E -> 0x00000B4E
  Offset 41: 2472 (0x9A8) bytes.  Value: 0x00000ADC -> 0x00000BDC
  Offset 42: 2518 (0x9D6) bytes.  Value: 0x00000A52 -> 0x00000B52
  Offset 43: 2524 (0x9DC) bytes.  Value: 0x00000611 -> 0x00000711
Offset count: 18
Hunk index: 1
  Offset 0: 78 (0x4E) bytes.  Value: 0x00000000 -> 0x00000EC0
  Offset 1: 88 (0x58) bytes.  Value: 0x00000000 -> 0x00000EC0
  Offset 2: 170 (0xAA) bytes.  Value: 0x00000000 -> 0x00000EC0
  <snip>

It looks like the CODE hunk is 0xD9C bytes, but the associated reloc table contains entries for 0x00000D9C and 0x00000D9E i.e. out of range. Would the assembler/linker be expected to retain the trailing zero data in this case?

a/b · 08 June 2022, 14:05

Quote:

Originally Posted by ross

i.e. insert a non-zero data value as the last variable.

Yup, that's what I've been doing in my code, so that modifed asm-pro can produce code+bss (or data+bss) hunks. It's one of the things I really missed in the entire asm-one family of assemblers (it can now strip all trailing zeroes in each code/data hunk regardless of where they came from, since doing a proper mixed hunk support would be way too complicated, considering the state of asm-pro source ><).

hop · 08 June 2022, 14:34

Quote:

Originally Posted by a/b

Yup, that's what I've been doing in my code, so that modifed asm-pro can produce code+bss (or data+bss) hunks.

Can you please tell me why do you want to generate code+bss (or data+bss) hunks? Why is this preferential to keeping bss separate? Wouldn't it just increase the file size?

phx · 08 June 2022, 14:52

Quote:

Originally Posted by hop

It looks like the CODE hunk is 0xD9C bytes, but the associated reloc table contains entries for 0x00000D9C and 0x00000D9E i.e. out of range.

That would be a serious bug, but as far as I can see the last reloc entries are at offset 0x9DC.

Quote:

Originally Posted by hop

Can you please tell me why do you want to generate code+bss (or data+bss) hunks? Why is this preferential to keeping bss separate? Wouldn't it just increase the file size?

Maybe multiple sections increase the chance for loading in a low- or highly-fragmented memory situation? Otherwise I would say since OS2.0 there are only advantages to use code-bss or data-bss sections.

hop · 08 June 2022, 14:58

Quote:

Originally Posted by phx

That would be a serious bug, but as far as I can see the last reloc entries are at offset 0x9DC.

Oh, so the location that is being relocated is withing the range, but the address it points to is not. I thought that because an offset in the same hunk space was being explicitly referenced, it would force the assembler/linker to preserve that offset in the code section.

Code:

SECTION	code
	move.w xpos,d0     ; reloc in range
	rts

xpos		dc.w	0	    ; referenced address out of range so trimmed
ypos		dc.w	0

I thought it would be more like

Code:

SECTION	code
	move.w xpos,d0     ; reloc in range
	move.w ypos,d0     ; reloc in range
	rts

xpos		dc.w	0	    ; referenced so won't be trimmed
ypos		dc.w	0	    ; referenced so won't be trimmed
zpos		dc.w	0	    ; not referenced so can be trimmed
wpos		dc.w	0	    ; not referenced so can be trimmed

a/b · 08 June 2022, 15:48

Quote:

Originally Posted by hop

Can you please tell me why do you want to generate code+bss (or data+bss) hunks? Why is this preferential to keeping bss separate? Wouldn't it just increase the file size?

To keep all code and/or data in a single hunk resulting in shorter and faster code (pc relative addressing for everything, all data accessible via single base address register, no relocation tables in exe, ...).
If empty tables (generated in run-time) are embedded into eg. data hunk, and sometimes there can be a lot of them, exe ends up being bloated by a bunch of zeroes. And by putting them into a separate bss hunk it negates what I said earlier. So with a mixed hunk I can have everything close in a hunk or two, and keep the exe small.

phx · 08 June 2022, 16:17

Quote:

Originally Posted by hop

Oh, so the location that is being relocated is withing the range, but the address it points to is not.

Correct.

Quote:

I thought that because an offset in the same hunk space was being explicitly referenced, it would force the assembler/linker to preserve that offset in the code section.

No. You are definitely allowed to reference the BSS-part of a code/data-bss section. It is absolutely legal, allocated memory.

A reason not to allow relocations in this region is because it is uninitialised, and the startup-code may clear it again.

hop · 08 June 2022, 16:37

This is all very intersting thanks. So I guess to generate a code-bss or data-bss section with vasm/vlink it's as simple as my original situation:

Code:

SECTION	code
	<whatever>
	rts

; All the following zero will be trimmed from code hunk but still be accounted for in hunk header. 
; The loader or application code must initialise as appropriate!
xpos		dc.w	0
ypos		dc.w	0

phx · 08 June 2022, 20:09

Yes. If you generate an object file (-Fhunk) and link it with vlink, without -Z option, then it will happen automatically.

Otherwise, if you let vasm generate the executable (-Fhunkexe), then you either need the option -databss or use

DX.W

instead of

DS.W

or

DC.W 0

.

07 June 2022, 22:57	#1
hop Registered User Join Date: Apr 2019 Location: UK Posts: 172	Mutable data in code section Sorry if this is a dumb question, but is it safe to store state in the code section of an Amiga hunk executable? Code: SECTION code <hardware code (copper/playfield/blitter> <code which updates xpos and ypos> rts xpos dc.w 0 ypos dc.w 0 SECTION bss <etc> I'm launching this as the first exe in the startup-sequence of an unexpanded A500 1.3 in WinUAE. The first time I can see that xpos and ypos are zero in the debugger on launch. When the exe quits I launch it again (t/exe) and I can see that xpos and ypos are NOT zero. I'm not sure if the values are just whatever is in their current address. If I move the data to the bss section all is well, but obviously BSS sections are cleared on launch. I know that it's probably not good practice to store state in with code due to 020 CPU caches and best practices, but I thought in this case it would work. Last edited by hop; 07 June 2022 at 23:02. Reason: removed confusing code

08 June 2022, 16:37	#19
hop Registered User Join Date: Apr 2019 Location: UK Posts: 172	This is all very intersting thanks. So I guess to generate a code-bss or data-bss section with vasm/vlink it's as simple as my original situation: Code: SECTION code <whatever> rts ; All the following zero will be trimmed from code hunk but still be accounted for in hunk header. ; The loader or application code must initialise as appropriate! xpos dc.w 0 ypos dc.w 0

08 June 2022, 20:09	#20
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	Yes. If you generate an object file (-Fhunk) and link it with vlink, without -Z option, then it will happen automatically. Otherwise, if you let vasm generate the executable (-Fhunkexe), then you either need the option -databss or use DX.W instead of DS.W or DC.W 0 .

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
VBCC: How to use small code/data models with nostdlib	Hedeon	Coders. C/C++	23	04 October 2023 01:10
SECTION CODE - Problem with chunks and FAST ram	KONEY	Coders. Asm / Hardware	18	12 July 2021 15:17
Adding data to proper SECTION make strange behaviour...	fstarred	Coders. Asm / Hardware	18	08 September 2018 11:20
Devpac: Data section in Chip-Mem	roger_bratseth	Coders. Asm / Hardware	6	14 May 2018 10:06
help optimising a section of code	h0ffman	Coders. General	15	02 March 2011 13:19

07 June 2022, 23:34	#3
hop Registered User Join Date: Apr 2019 Location: UK Posts: 172	Thanks. It must be a memory stomp very early on in the code. I'll keep digging.

08 June 2022, 06:58	#5
a/b Registered User Join Date: Jun 2016 Location: europe Posts: 1,039	As already noted, the problem is code+bss hunk. Your first "code" hunk is $368 lwords allocated and $367 actual, meaning the last lword is bss, and is never initialized under KS1.x. The first time it happens to be a zero, so everything works ok. You have to explicitely initialize that lword (x/y coord, right?) with your code, before using it, or tell the assembler to produce pure code hunk and alwalys include trailing zero data as part of it and not as bss (not sure why it's doing it, DC.W is not DS.W, and it shouldn't be handled as bss).

08 June 2022, 11:52	#10
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,496	Explanation: The default behaviour of vasm and vlink is to generate programs for AmigaOS2.0+. Which means that vlink will always remove trailing zero-bytes (which have no relocation attached), while vasm will always use short-relocs (HUNK_RELOC32SHORT). Admittedly, this is quite stupid, because either both tools should use both features at all time, or none of them. But this is historical, and I cannot easily change that now. TL;DR? For Kickstart 1.x: vasm: -kick1hunks vlink: -Z (or initialise code-bss/data-bss yourself) For OS2.0+: vasm: vlink: -Rshort (optional)

08 June 2022, 12:01	#11
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	There is also a third way: xpos dc.w 0 ypos dc.w 0 cpos dc.w 1 i.e. insert a non-zero data value as the last variable. So you no longer have to worry about compiler / linker specific (default) options

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)