English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 09 May 2019, 11:37   #1
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 67
DS directive - is it zeroed?

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?
Antiriad_UK is offline  
Old 09 May 2019, 11:52   #2
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,825
Quote:
Originally Posted by Antiriad_UK View Post
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.
ross is offline  
Old 09 May 2019, 12:01   #3
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,503
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.
meynaf is offline  
Old 09 May 2019, 12:09   #4
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 67
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...
Antiriad_UK is offline  
Old 09 May 2019, 12:18   #5
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,825
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.

Last edited by ross; 09 May 2019 at 12:30. Reason: latter..
ross is offline  
Old 09 May 2019, 12:48   #6
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,703
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.
Photon is offline  
Old 09 May 2019, 13:27   #7
Antiriad_UK
Registered User

 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 67
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.

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

Data: ds.w 16
Antiriad_UK is offline  
Old 09 May 2019, 14:02   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,409
Quote:
Originally Posted by ross View Post
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.

Quote:
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.

Quote:
Originally Posted by Photon View Post
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?

Quote:
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 is offline  
Old 09 May 2019, 14:09   #9
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,409
Quote:
Originally Posted by Antiriad_UK View Post
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...
phx is offline  
Old 12 May 2019, 00:43   #10
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,703
Quote:
Originally Posted by phx View Post
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.
Photon is offline  
Old 12 May 2019, 12:30   #11
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 916
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?
hooverphonique is offline  
Old 12 May 2019, 12:59   #12
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,825
Quote:
Originally Posted by hooverphonique View Post
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 is offline  
Old 12 May 2019, 13:00   #13
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,825
Tested and yes, an extension that works exclusively with KS2.0+

Code:
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.
ross is offline  
Old 12 May 2019, 21:47   #14
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,409
Quote:
Originally Posted by Photon View Post
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.

Quote:
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.
phx is offline  
Old 13 May 2019, 20:49   #15
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,703
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.

Quote:
Originally Posted by Antiriad_UK View Post
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.

Quote:
Originally Posted by Antiriad_UK View Post
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.:

Code:
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.

Last edited by Photon; 13 May 2019 at 21:18.
Photon is offline  
Old 13 May 2019, 21:37   #16
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,503
Quote:
Originally Posted by Photon View Post
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.
meynaf is offline  
Old 13 May 2019, 23:06   #17
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 684
Quote:
Originally Posted by meynaf View Post
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.
alpine9000 is offline  
Old 13 May 2019, 23:13   #18
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,703
Quote:
Originally Posted by meynaf View Post
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.
Photon is offline  
Old 13 May 2019, 23:53   #19
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 916
Quote:
Originally Posted by Photon View Post
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).
Quote:
Originally Posted by Photon View Post
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.
hooverphonique is offline  
Old 14 May 2019, 08:39   #20
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,503
Quote:
Originally Posted by Photon View Post
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.
meynaf is offline  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
vasm basereg example directive mcgeezer Coders. Asm / Hardware 5 22 December 2018 23:38
Issues with ORG directive (vasm + FS-UAE) Maggot Coders. Asm / Hardware 6 21 November 2018 19:48
REPT directive in vasm phx Coders. Asm / Hardware 8 01 October 2014 21:48
AsmOne even directive...? pmc Coders. General 30 04 December 2009 09:33
Invalid Directive Kimmo support.WinUAE 1 23 July 2004 11:23

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.09309 seconds with 13 queries