DS directive - is it zeroed?

[Photon]

Antiriad_UK seems intent on finding out how it works, and I think there's a fast way.

Let's disregard the other two questions, BSS sections and whether the data is cleared for now.

Assemble this to a release exe:

SECTION DCBvsDS,CODE_C
Start:
	move.l #Data1,a0
	move.l #Data2,a1
	move.l #Data3,a2
	moveq #0,d0
	rts
Data1:	dcb.b 1000,0
	rts
Data2:	dcb.b 1000,0
Data3:	dcb.b 1000,0

Of course, with DCB there, we expect the file to be 3060 bytes+a few bytes relocs. So, total 3088 bytes.

Now change all 3 DCB to DS, and use your preferred Assembler and preferred options.

If each DS is translated into markers interpreted by the OS1.3+ hunk parser, what we should see is an exe file size of 88 bytes+a few bytes for the DS, say 24 bytes extra, so total 112.

If that's true only for the last DS, we should see a file size of 2088+fewer bytes extra, say total 2096.

~

So, values very near these totals should tell us if DS is recognized by 1) the OS, 2) the Assembler, or 3) none. If the total size is larger than one of the three totals in bold by more than 4 bytes, the assumption is that your Assembler modifies your code and/or your sections.

[Kalamatee]

@Antiriad_UK

BSS sections are to store uninitialized values. While strictly speaking they dont need to be initialized, due to statically-allocated objects without an explicit initializer in "c" being initialized to zero (and using bss to store them), in practice ALL(*) operating systems do clear real BSS section(s) of a file.

dc.x explicitly defines a value, and as such it is expected to be initialized before use so has to be stored in the file in a normal data section, however ds.x handling is entirely assembler/compiler dependent. Typically it will be stored in BSS (so that the least space is used on disk), which means the OS will expand it to the correct size and initialize it to 0, in case the binary was written using "C" or another language that expects it to be set to 0 - some however will try to do tricks to combine it with other sections, though it will now take up more disk space since it is no longer expanded in the same manner as a normal BSS section, and will not necessarily be initialized to any specific value.

Edit: Really they are talking about 2 different things though. dc/ds are not referring to how it is stored on disk but represented in memory. BSS refers to how data is actually stored on disk and loaded by the system.

so to answer your actual original question -:

In ASMOne/Pro there is a preference option for "DS Clear" but the manual says that outside of ASMOne (final exe) they will NOT be cleared.

Is this a difference in assemblers or is it just the ASM one manual I'm misunderstanding and it's only talking about BSS sections?

when you are doing things _inside_ of ASMOne it will either a> treat the code the same inside of ASMOne, as you would expect if you loaded the binary in the OS (so if it is putting it in its "own" special "bss"-like section that isn't really bss, it will not be initialized) or b> initialize it when you use it in ASMOne - though it warns you the final binary will not initialize it (because of the previously mentioned special way of storing it..). So yes the difference is in the assembler (and how you are using it ) because of the special way it is storing the value. if you explicitly put the value in a "real" BSS section or the compiler puts it there (which is the more general behavior) it will be initialized to 0.

where the values are stored in a file isn't strictly defined by the mnemonics, so an assembler/compiler etc are free to choose which section _they_ think best suits the data.

I hope that helps clarify things.

* - there are a few operating systems/crt's that can use a special BSS format that allows some parts to be initialized and others not, but it isn't the general expected behavior.

[meynaf]

Originally Posted by Photon

Antiriad_UK seems intent on finding out how it works, and I think there's a fast way.

Let's disregard the other two questions, BSS sections and whether the data is cleared for now.

Assemble this to a release exe:

SECTION DCBvsDS,CODE_C
Start:
    move.l #Data1,a0
    move.l #Data2,a1
    move.l #Data3,a2
    moveq #0,d0
    rts
Data1:    dcb.b 1000,0
    rts
Data2:    dcb.b 1000,0
Data3:    dcb.b 1000,0

Of course, with DCB there, we expect the file to be 3060 bytes+a few bytes relocs. So, total 3088 bytes.

Now change all 3 DCB to DS, and use your preferred Assembler and preferred options.

If each DS is translated into markers interpreted by the OS1.3+ hunk parser, what we should see is an exe file size of 88 bytes+a few bytes for the DS, say 24 bytes extra, so total 112.

If that's true only for the last DS, we should see a file size of 2088+fewer bytes extra, say total 2096.

~

So, values very near these totals should tell us if DS is recognized by 1) the OS, 2) the Assembler, or 3) none. If the total size is larger than one of the three totals in bold by more than 4 bytes, the assumption is that your Assembler modifies your code and/or your sections.

There is nothing such as markers that would make the exe go down to 112 bytes ; AOS by itself does not crunch sections. Any Amiga asm doing that would be severely broken.
Of course an asm putting garbage data instead of zeroes for DS is also broken

I get 3088 bytes. An assembler recognising the MOVEA and converting it to PC-relative LEA would go down to 3056.

Strict minimum is 1056 but then the exe is no longer ks1.3 compatible.
If an asm does this conversion, it will not do that just for last DS, that would be pretty stupid (imagine it's ds.b 1, lol) - and the OS itself has absolutely no such concept as "DS".

[Photon]

Meynaf, I agree it would be "awesome if true", but I'm open and looking for facts. If it's possible, someone should be able to post a smaller size together with 1) Assembler, 2) settings, and 3) OS compatibility.

The code snippet is made so that it shows what putting DS in your source means to the combination of these 3 things.

And this is why Antiriad_UK posted, at least I read it as he wants to know what happens. (The statements in the manuals I already answered in my 2nd post, but we all seek knowledge.)

[Kalamatee]

Originally Posted by Kalamatee

@Antiriad_UK

when you are doing things _inside_ of ASMOne it will either a> treat the code the same inside of ASMOne, as you would expect if you loaded the binary in the OS (so if it is putting it in its "own" special "bss"-like section that isn't really bss, it will not be initialized) or b> initialize it when you use it in ASMOne - though it warns you the final binary will not initialize it (because of the previously mentioned special way of storing it..). So yes the difference is in the assembler (and how you are using it ) because of the special way it is storing the value. if you explicitly put the value in a "real" BSS section or the compiler puts it there (which is the more general behavior) it will be initialized to 0.

where the values are stored in a file isn't strictly defined by the mnemonics, so an assembler/compiler etc are free to choose which section _they_ think best suits the data.

If it helps - don't think of ds.x in terms of how it is stored on disk, just in how it is used in memory. unless you explicitly ask for it to be put in a section on disk, the assembler/compiler/linker will "optimize" its location based upon how it is actually used, and you should always expect ds.x to have an uninitialized value.

e.g. If the compiler/assembler/linker in question decides it saves more space/performs better to use a shorter addressing mode and localize the data represented by ds.x, it will store it in the same section using those preferred instructions. when this is now loaded by the os the value is "uninitialized" and could contain anything.

If you have explicitly asked for it to be put in a real bss section you can expect it to be initialized to 0.

[Kalamatee]

Originally Posted by Photon

Meynaf, I agree it would be "awesome if true", but I'm open and looking for facts. If it's possible, someone should be able to post a smaller size together with 1) Assembler, 2) settings, and 3) OS compatibility.

erm... surely. ..

SECTION DCBvsDS,CODE_C
Start:
    move.l #Data1,a0
    move.l #Data2,a1
    move.l #Data3,a2
    moveq #0,d0
    rts

; though really you would move this to BSS also ..
Data1:    dsb.b 1000,0
    rts

SECTION MYBSS,BSS
Data2:    dsb.b 1000,0
Data3:    dsb.b 1000,0

?

the result also being A0 _could_ contain a random value but A!/A2 will contain 0 when loaded by the OS.

[Don_Adan]

Every good assembler (used by me) zeroed ds.x area.
But assemblers different handles f.e next code:
rts
cnop 0,4
rts

in cnop 0,4 place, I see 3 types:
1. dc.w 0

2. nop

3. dc.w $xxxx (random value)

[Photon]

Originally Posted by Kalamatee

erm... surely. ..

My test code mustn't be altered - it's nothing special, but it's written this way to show the current contention in the thread - what DS does. (As I write, the original question has been answered as stated.)

I.e. for us to find out DS behavior you can perform this test on your combination of choice and report results

Also: don't double-post: this is not allowed. (To avoid this, use the Multi-quote button.)

[ross]

Originally Posted by Kalamatee

the result also being A0 _could_ contain a random value but A!/A2 will contain 0 when loaded by the OS.

A0-A2 certainly they won't be 0
This is the reason I always use lea (or strictly movea if I need data in Ax registers).

Anyway if only a single SECTION is allowed, only the last 2000 bytes can be in the 'CODE_BSS' part and zeroed by LoadSeg() on KS2.0+.
No alternatives.

[meynaf]

Originally Posted by Photon

Meynaf, I agree it would be "awesome if true", but I'm open and looking for facts. If it's possible, someone should be able to post a smaller size together with 1) Assembler, 2) settings, and 3) OS compatibility.

The code snippet is made so that it shows what putting DS in your source means to the combination of these 3 things.

And this is why Antiriad_UK posted, at least I read it as he wants to know what happens. (The statements in the manuals I already answered in my 2nd post, but we all seek knowledge.)

You keep looking for mysteries where there is none. The situation is really very simple. It's not "awesome if true", it's simply true.

Regardless of settings, PhxAss will always zero DS.x outside of BSS. Most assemblers, except maybe the really broken ones, also will.
Regardless of the assembler and settings, the OS will always zero true BSS sections and only 1.x will not zero bss part of CODE/DATA sections.
What's not clear in that ?

Originally Posted by Kalamatee

If it helps - don't think of ds.x in terms of how it is stored on disk, just in how it is used in memory. unless you explicitly ask for it to be put in a section on disk, the assembler/compiler/linker will "optimize" its location based upon how it is actually used, and you should always expect ds.x to have an uninitialized value.

e.g. If the compiler/assembler/linker in question decides it saves more space/performs better to use a shorter addressing mode and localize the data represented by ds.x, it will store it in the same section using those preferred instructions. when this is now loaded by the os the value is "uninitialized" and could contain anything.

While a compiler may eventually perform this kind of thing, an assembler will not do a thing "upon how it is actually used"...

Originally Posted by Kalamatee

the result also being A0 _could_ contain a random value but A!/A2 will contain 0 when loaded by the OS.

What is pointed to by A0 (not A0 itself !) contains 0, not a random value.
I don't know of an assembler that would do otherwise.

Originally Posted by Don_Adan

Every good assembler (used by me) zeroed ds.x area.
But assemblers different handles f.e next code:
rts
cnop 0,4
rts

in cnop 0,4 place, I see 3 types:
1. dc.w 0

2. nop

3. dc.w $xxxx (random value)

PhxAss has the option to use either 0 or nop padding.
And every good enough assembler should be more or less similar.

[phx]

Originally Posted by Photon

If it's possible, someone should be able to post a smaller size together with 1) Assembler, 2) settings, and 3) OS compatibility.

1) vasmm68k
2) -databss option is needed to enable this feature
3) OS2.0+, of course. For Kickstart 1.x you have to clear the Databss-region yourself.

frank@sun cat databsstest.s
        SECTION DCBvsDS,CODE_C
Start:
        move.l #Data1,a0
        move.l #Data2,a1
        move.l #Data3,a2
        moveq #0,d0
        rts
Data1:  dcb.b 1000,0
        rts
Data2:  dcb.b 1000,0
Data3:  dcb.b 1000,0

frank@sun vasmm68k_mot -Fhunkexe -nosym -databss databsstest.s
vasm 1.8f (c) in 2002-2019 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.3e (c) 2002-2019 Frank Wille
vasm motorola syntax module 3.12b (c) 2002-2019 Frank Wille
vasm hunk format output module 2.10 (c) 2002-2019 Frank Wille

DCBvsDS(acrx2):         3018 bytes
frank@sun ll a.out
-rw-r--r--  1 frank  users  1056 May 16 16:46 a.out
frank@sun hexdump -C a.out
00000000  00 00 03 f3 00 00 00 00  00 00 00 01 00 00 00 00  |................|
00000010  00 00 00 00 40 00 02 f3  00 00 03 e9 00 00 00 ff  |....@...........|
00000020  41 fa 00 0e 43 fa 03 f4  45 fa 07 d8 70 00 4e 75  |A...C...E...p.Nu|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000410  00 00 00 00 00 00 00 00  4e 75 4e 71 00 00 03 f2  |........NuNq....|
00000420

[phx]

OMG! Anybody spotted the bug in the last line of the executable's hexdump?

It's always good to make these tests. Fixed with tomorrow's vasm-snapshot.

[a/b]

Hunk padded with 2 random bytes (hunk size is in LWs, but Data2 is at a non-LW aligned offset), thus trashing first 2 bytes of Data2?

Or 3 "bugs" in line 3 where movea is converted to lea? :P Yeah, I don't like that :P.
If I write movea, I mean it unless I specify +opt or similar. But don't really want to argue about it, so it's OK.

[meynaf]

Originally Posted by phx

OMG! Anybody spotted the bug in the last line of the executable's hexdump?

It's always good to make these tests. Fixed with tomorrow's vasm-snapshot.

Indeed the first 2 bytes of Data2 are not gonna be zero. Damned NOP padding (but 4E71 are not random bytes).

[phx]

Correct! I thought it would be a good idea to pad code sections with NOP, when their size is not a multiple of four. So a linker can merge two halfs of a function without any risk.

But I didn't have -databss in mind. So now I'm leaving it zero when the filesize is smaller than the section size.

Originally Posted by a/b

Or 3 "bugs" in line 3 where movea is converted to lea? :P Yeah, I don't like that :P.

Yes, personal taste. I like to have optimizations enabled all the time, because situations where the instruction size matters are rare (e.g. jump-tables).

Run vasm with -devpac in Devpac-compatibility mode and there will be no optimizations until you enable them. Or make sure there will be none with an "OPT O-" directive on top or a -no-opt command line option.

[Bruce Abbott]

Originally Posted by phx

-databss option is needed to enable this feature

vasm documentation says:-

"-databss Try to shorten sections in the output file by removing zero words without re-location from the end. This technique is only supported by AmigaOS 2.0 and higher."

But there is a well-known technique that involves adding 'bss' to the end of a code or data section by making the size in the hunk length table (which is used to allocate memory) larger than the hunk's actual size. This technique works in all OS versions.

ProAsm and Barfly use the 'dx' directive to allocate space in these 'extended' code/data sections. PhxAss accepts dx for 'compatibility', but doesn't appear to to honour it (has the same affect as ds).

Any chance of vasm supporting this feature?

I like to have optimizations enabled all the time, because situations where the instruction size matters are rare (e.g. jump-tables).

I like to have optimizations enabled never, because I want the assembler to do what I tell it - not change things behind my back.

Does anyone know how to stop Barfly from 'optimizing' cmp to cmpi ?

[ross]

Originally Posted by phx

It's always good to make these tests. Fixed with tomorrow's vasm-snapshot.

Probably it's time to give to vasm a serious try (I'm obsolete, I'm too used to native assemblers )
There is a win32 (or 64) binary available for the snapshots?

[phx]

Originally Posted by Bruce Abbott

But there is a well-known technique that involves adding 'bss' to the end of a code or data section by making the size in the hunk length table (which is used to allocate memory) larger than the hunk's actual size.

That's what we are talking about in this thread...

This technique works in all OS versions.

No. As mentioned in earlier posts, 1.x doesn't clear this area.

ProAsm and Barfly use the 'dx' directive to allocate space in these 'extended' code/data sections. PhxAss accepts dx for 'compatibility', but doesn't appear to to honour it (has the same affect as ds).

Any chance of vasm supporting this feature?

Sure. I like this idea. But I see a problem with labels.

The space allocated by DX will have to be moved to the end of a section, which means you cannot expect it to be at the same location as you see it in the source. So what happens when you write:

mydxspace:
        dx.l    1

The space allocated by DX moves, but mydxspace does not! The assembler cannot know what the label is refering to. It could also mark the end of a memory region before it.

I like to have optimizations enabled never, because I want the assembler to do what I tell it - not change things behind my back.

That's fair enough. So you also check the distances of all your branches manually to see if they are .b or .w?

Does anyone know how to stop Barfly from 'optimizing' cmp to cmpi ?

Unfortunately many assemblers are doing it and I always hated that too, so I made sure PhxAss and vasm assemble exactly what you write. Also makes such an assembler work better with reassemblers.

[phx]

Originally Posted by ross

Probably it's time to give to vasm a serious try (I'm obsolete, I'm too used to native assemblers )
There is a win32 (or 64) binary available for the snapshots?

No. The binary snapshots are built automatically over night on my NetBSD server with vbcc. There is no Windows target.

[Don_Adan]

Originally Posted by phx

Correct! I thought it would be a good idea to pad code sections with NOP, when their size is not a multiple of four. So a linker can merge two halfs of a function without any risk.

But I didn't have -databss in mind. So now I'm leaving it zero when the filesize is smaller than the section size.


Yes, personal taste. I like to have optimizations enabled all the time, because situations where the instruction size matters are rare (e.g. jump-tables).

Run vasm with -devpac in Devpac-compatibility mode and there will be no optimizations until you enable them. Or make sure there will be none with an "OPT O-" directive on top or a -no-opt command line option.

Padding code sections with NOP is not good idea. I never like this. Especially when I resourced code. Only padding with dc.w 0 or $4AFC in debug mode has sense for me. I dont like auto optimisations too. If i used bra.w then it must be bra.w, not bra.b.