DS directive - is it zeroed?

[Antiriad_UK]

Hi,
I always assumed that DS.w type sections are zeroed in memory when in a CODE/DATA section. And that they were not zeroed in a BSS section.

The devpac manual says "These directives will reserve memory locations and the contents will be initialised to zeros......except in the case of true BSS sections".

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?

[ross]

Originally Posted by Antiriad_UK

The devpac manual says "These directives will reserve memory locations and the contents will be initialised to zeros......except in the case of true BSS sections".

Wrong assertion. BSS hunk are always zeroed by system segment loader.

The devpac manual maybe means that in the case of CODE and DATA section the space reserved and zeroed with DS is actually present in the final file structure, while for BSS the allocation is left to the system.

[meynaf]

True BSS hunks are always zeroed.
If you use DS right in the middle of the code, it's like DC with a value of zero.

However, there can be some empty space at the end of CODE/DATA sections. This means allocated area is bigger than actual contents : the extra data is considered like BSS. It's sometimes called CODE_BSS or DATA_BSS sections.
This is supported only in V37+, or something like that.

[Antiriad_UK]

Ok thanks that's what I'd assumed (although didn't realise BSS was zeroed). So what is the ASMOne "DS Clear" preference option talking about?

"DS Clear - If ON, ASM-One will clear BSS sections for you
automatically. But remember, the Amiga will NOT clear BSS
sections for you if you start your program outside ASM-One."

That doesn't make sense if the system segment loader zeros it...

[ross]

Yes this doesn't make sense.

Like meynaf explained there is a possible exception in the case of the DS directive used at the end of a section
(CODE or DATA but this does not concern BSS).

Unfortunately there is no standard among the various assemblers (you are lucky if is supported or there is a specific option).

The structure of Amiga executable files includes an initial header where the number, type, amount and type of memory required by the various sections are specified.
So the allocation is made immediately without taking into account the space actually on disk used by the section itself.
If the section uses less space than the one initially declared then the final part can be used as a BSS space (call it DATA_BSS space..), but the assembler must have foreseen a similar use and refer to it adequately.

In this case there is a substantial difference between KS1.x and KS2.0+.
In the former case that space is NOT cleared by the system loader, in the latter YES.

[Photon]

Yes, you should never assume BSS space is cleared. DS can be used in all sections, not just BSS.

Unfortunately on later Kickstarts, the OS interferes and clears them with a slow routine, when in fact you just wanted some workspace, which means you wouldn't need to clear it at all. And if you wanted it or part of it cleared, you'd like to do it with an optimal routine.

It's not so nice to click a program, and just because it declared some BSS, there's a second of extra delay starting it, instead of opening right away.

[Antiriad_UK]

I just did some tests in ASMOne in a normal CODE section.

Unless "DS Clear" is enabled then DS directives are not zeroed after assembling. So that's very different behaviour to devpac.

SECTION test,code
move.w #1,Data
rts

Data: ds.w 16

[phx]

Originally Posted by ross

Unfortunately there is no standard among the various assemblers (you are lucky if is supported or there is a specific option).

True. And there are not so many development tools supporting it. I can only speak for vlink and vasm. vasm's "hunkexe" output module supports the -databss option to enable it. In vlink it is unfortunately the other way around and data-bss is the default, as it is also commonly used by other output formats, like ELF. Here you can disable this feature with -Z.

BTW, the most frequent use case of DATA_BSS is Small Data, which is supported by a lot more tools.

If the section uses less space than the one initially declared then the final part can be used as a BSS space (call it DATA_BSS space..), but the assembler must have foreseen a similar use and refer to it adequately.

The assembler does nothing here, and there are also no special directives for it. Usually supporting DATA_BSS sections is the task of the linker, which looks for zero bytes without relocation at the end of a section. There is nothing in an object file which could otherwise indicate DATA_BSS.

The only thing the developer could do to allow DATA_BSS is to move uninitialized and zero space (usually DS and DC 0 directives) to the end of a code or data section and hope for a smart linker or output-module.

Originally Posted by Photon

Yes, you should never assume BSS space is cleared.

What?
Under AmigaOS, and most other sane operating systems, you definitely can! The only case where you might have to clear BSS yourself is when the target is some kind of development board, without any form of OS and executable file format (e.g. loading Motorola S-Records or other raw formats).

Or are you talking about DATA_BSS space here?

It's not so nice to click a program, and just because it declared some BSS, there's a second of extra delay starting it, instead of opening right away.

Must be a huge BSS section. Usually one millisecond more or less makes no difference after waiting for a mass-storage loader.

[phx]

Originally Posted by Antiriad_UK

Unless "DS Clear" is enabled then DS directives are not zeroed after assembling. So that's very different behaviour to devpac.

I was about to say: looks like a bug to me. But originally DS only means "Declare Storage" (uninitialized). This storage is certainly always 0 in a BSS section, but it is not necessarily 0 in initialized sections. "DS.B x" is more like "* = * + x" in ancient sources. It's just like most assemblers will zero it automatically, which makes it kind of a standard...

[Photon]

Originally Posted by phx

What?
Under AmigaOS, and most other sane operating systems

So AmigaDos 1.3 is insane.

No, you really need some way to allocate space without clearing it with a crap slow routine, and AmigaDOS provides that in all versions with Alloc.

If I wrote a 4K I certainly wouldn't want anything to interfere just because I need the remaining 400K Chipmem for buffers.

The same would certainly be true for any decompressor adding a BSS hunk. Performance would be absolutely through the floor and the decompressor would be made worthless by the OS if it did that.

I think one has opposite views on this depending on whether you're on a slow computer or a fast one. So this has nothing to do with target platform or anything like that, it's just whether you'd like the OS to automatically do it for you, slowly, every time. It certainly shouldn't by default, is my view.

[hooverphonique]

As far as I remember, the MEMF_* flags are used in the hunk structure to specify section memory requirements. Could it be the case that this includes MEMF_CLEAR, so the executable itself can specify if it wants a section cleared or not?

[ross]

Originally Posted by hooverphonique

As far as I remember, the MEMF_* flags are used in the hunk structure to specify section memory requirements. Could it be the case that this includes MEMF_CLEAR, so the executable itself can specify if it wants a section cleared or not?

If I'm not mistaken it's unfortunately an extension to the hunk structure that works exclusively with KS2.0+.

[ross]

Tested and yes, an extension that works exclusively with KS2.0+

value = read_uint32(f)
hunk_type = value & 0x3FFFFFFF
mem_flags = value & 0xC0000000) >> 29
if mem_flags == MEMF_CHIP | MEMF_FAST:
    mem_flags = read_uint32(f) & (1 << 30)
mem_flags = mem_flags | MEMF_PUBLIC

The exe fail to load on KS1.x.

[phx]

Originally Posted by Photon

So AmigaDos 1.3 is insane.

Then you are talking about DATA-BSS hunks? Otherwise there is no difference for real BSS hunks between 1.3 and 2.0+.

And yes, 1.3 is insane, because that was a bug which 2.0 fixed.

If I wrote a 4K I certainly wouldn't want anything to interfere just because I need the remaining 400K Chipmem for buffers.

I understand your argument and I agree. A fourth section type for really uninitialized data could have been useful in certain situations.

[Photon]

phx: What bug?

• BSS sections are for declaring spaced out labels that are reloc'ed. This requires run-time intervention by the OS (or another run-time hunk parser) and is an OS hunk type.
• DS provides the spacing; "DCB/BLK without the fill-value".
• I'm sure you can find no mention of automatic clearing of BSS hunks in any Assembler manual. After all, you're declaring the space to put what you want there, not zeroes.

Originally Posted by Antiriad_UK

I always assumed that DS.w type sections are zeroed in memory when in a CODE/DATA section. And that they were not zeroed in a BSS section.

The devpac manual says "These directives will reserve memory locations and the contents will be initialised to zeros......except in the case of true BSS sections".

Then DevPac will do that when running it from the Assembler, and not clear DS in BSS sections.

Originally Posted by Antiriad_UK

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.

Then AsmOne/Pro will clear DS when running it from the Assembler if that option is on, but warns that DS can contain random junk and BSS sections might not be cleared run-time. Which is the purpose of using DS over DCB/BLK.

~

Best practice is to use DCB/BLK for space that is to be initialized, and DS for space that should be uninitialized, i.e.:

SECTION Screenbuffers,BSS_C
Screen0: ds.l 320*256*5/32
Screen1: ds.l 320*256*5/32

is how you would declare a double-buffered screen, and this should assemble faster in Assemblers who follow the meaning.

So the manuals have nothing to do with the Kickstart behavior, because you understood the directive and used it correctly, so you're expecting junk in those buffers and will add code to clear it/fill it with your data. (Promise! )

I'm not sure what the meaning is with the extra clearing proposedly done on KS2+, but if so and you coded using best practice, the declared space is cleared twice.

[meynaf]

Originally Posted by Photon

I'm not sure what the meaning is with the extra clearing proposedly done on KS2+, but if so and you coded using best practice, the declared space is cleared twice.

True BSS sections are cleared by the OS regardless if you want it or not, and not only by Amiga Kickstart : Atari ST and MacOS 68k all clear BSS sections as well. So the best practice is to assume zeroes when using DS.
If you're unhappy with this, use AllocMem.

The error is in the interpretation of how a BSS section works.

Only part that is not cleared is unused area of CODE/DATA sections, a bug present in 1.x that has been fixed in 2.0.

[alpine9000]

Originally Posted by meynaf

True BSS sections are cleared by the OS regardless if you want it or not, and not only by Amiga Kickstart : Atari ST and MacOS 68k all clear BSS sections as well. So the best practice is to assume zeroes when using DS.
If you're unhappy with this, use AllocMem.

The error is in the interpretation of how a BSS section works.

Only part that is not cleared is unused area of CODE/DATA sections, a bug present in 1.x that has been fixed in 2.0.

I think we can thank the C implementation on original Unix for the “bss must be cleared” behavior.

[Photon]

Originally Posted by meynaf

The error is in the interpretation of how a BSS section works.

But we just confirmed BSS hunks are not cleared on KS1.3.

The interpretation is perfectly clear. You add a BSS section to declare space that should be allocated at runtime, instead of bloating the exe.

There is no handling of DS in CODE/DATA sections and hunks other than for the Assembler to convert them to DCB/BLK and bloating the exe.

And that is exactly what actually happens, whatever preference the Assembler/Compiler has for it being cleared or not.

So we're learning something here. What on earth do you mean by DS in CODE/DATA sections?

Nobody who wants that means anything. Or perhaps they mean they shouldn't have forgotten to turn the DS into DCB/BLK. Catch my drift?

A BSS section/hunk is a BSS section/hunk, not a CODE or DATA section/hunk. There's no need for a fourth type phx, it's just someone done gone and f'ed up the meaning provided in the first place; the reason for the existence of BSS sections/hunks.

I really hope someone understands this. "Niklaus Wirth would not approve of implementations." And he knows a thing or two.

[hooverphonique]

Originally Posted by Photon

There is no handling of DS in CODE/DATA sections and hunks other than for the Assembler to convert them to DCB/BLK and bloating the exe.

Yes, there is. The amount of memory that gets allocated for a hunk can be bigger than the amount of data in the hunk (in the file).

Originally Posted by Photon

So we're learning something here. What on earth do you mean by DS in CODE/DATA sections?

It means extending the memory allocated beyond the size of the data.

[meynaf]

Originally Posted by Photon

But we just confirmed BSS hunks are not cleared on KS1.3.

This is where the error lies - BSS hunks are cleared even on KS1.3. That some assemblers writers apparently didn't know, doesn't change the fact.
BSS hunks and unused areas at the end of CODE/DATA are two different things.