Devpac - CNOP in a BSS Section

[IFW]

Then you can use data section, or use one of the work arounds posted earlier, except for the one posted by Don which is incorrect - just calculate the number of bytes generated if the difference from the start of the section is e.g. 50...

[Don_Adan]

Originally Posted by phx

No. It doesn't. "section bss" is a code section, named "bss". Watch the $3e9 hunk type in your output. "section name,bss" or just "bss" would be a real bss section. Omitting the section type lets it default to code.


Correct. The first data in a section is always guaranteed to start on a 8-byte boundary. When a linker combines sections, the following data is still guaranteed to start on a 4-byte boundary, as a hunk size is always a multiple of 4.

Of course not, first data in a section is always guaranteed to start on a 4-byte boundary, or you must use modified exec.library, if you want to start f.e. on a 8 byte boundary. You can read Jim Drew's posts about random Fusion speed.

[phx]

What makes you think so? All sections I have ever seen start on an 8-byte boundary in memory, because LoadSeg() allocates them with AllocMem().

Which post of Jim Drew? Any links?

[matthey]

Originally Posted by phx

What makes you think so? All sections I have ever seen start on an 8-byte boundary in memory, because LoadSeg() allocates them with AllocMem().

Which post of Jim Drew? Any links?

Jim was using a patch which aligned memory allocations more so they would be compatible with his Fusion Mac Emulator which uses MOVE16. It's not in widespread use but Chris Hodge's TLSFMem is:

Originally Posted by Chris Hodges in TLSFMem.readme

Q: Does this 103% stuff mean it wastes memory (internal fragmentation)?
A: No. It only needs four extra bytes per allocation. The only internal
fragmentation happening is for its alignment of 16 bytes per allocation.

...

- Uses four additional bytes per allocation and has a minimum chunk size of
16 instead of 8.

This makes CNOP 0,16 useful to align to a cache line. It should speed up memory copies with a CopyMem patch that uses MOVE16 as well as vbcc floating point although the difference would be small (a few percent?).

Devpac missing alignment functionality isn't as bad as with C. Without GCCisms, one must use _Alignas from C11. Vbcc does support __alignof already so something like the following C11 stdalign.h should be possible.

#ifndef __STDALIGN_H
#define __STDALIGN_H

/* #define __alignas _Alignas */
#define __alignof _Alignof

#define __alignas_is_defined 0
#define __alignof_is_defined 1

#endif /* __STDALIGN_H */

All we need is __alignas support in vbcc but this is trickier than __alignof beause of limitations on minimum and maximum valid alignment. It might be worth suggesting to Volker. I hope he isn't waiting for vbcc to be 100% C99 compliant before he adopts some good ideas from C11 .

[JimDrew]

Devpac can use any memory alignment (CNOP 0,16 - CNOP 0,128, etc.) I used CNOP 0,16 throughout FUSION, PCx, and anything that is going to be doing a bunch of stuff that I want to be guaranteed to be entirely in the cache.

[matthey]

Originally Posted by JimDrew

Devpac can use any memory alignment (CNOP 0,16 - CNOP 0,128, etc.) I used CNOP 0,16 throughout FUSION, PCx, and anything that is going to be doing a bunch of stuff that I want to be guaranteed to be entirely in the cache.

Sure, you can specify CNOP 0,16 in Devpac but will you get it without a patch to AmigaOS that aligns memory allocations or hunks to more than 8 byte alignment? The start of the hunk has to have the same alignment or better than the CNOP alignment specified or the alignment may be less than requested.

[phx]

Bigger alignments than 8 make sense when you don't use the AmigaDOS hunk format, but assemble for an absolute address.

Let's say you start your code with "org $10000". This will allow alignments up to "cnop 0,65536"...

[JimDrew]

Originally Posted by matthey

Sure, you can specify CNOP 0,16 in Devpac but will you get it without a patch to AmigaOS that aligns memory allocations or hunks to more than 8 byte alignment? The start of the hunk has to have the same alignment or better than the CNOP alignment specified or the alignment may be less than requested.

You do if you use a custom hunk loader! ALL of my programs use a loader program that locates ALL code hunks on a 16 byte alignment. This the "patch" that was referred to early. It's not really a patch, its an executable loader program called "load", ie: load <filename>

For PCx the script file was:

RUN >NIL: <NIL: load PCx.dat

The load program makes AIBB, SysInfo, and a variety other benchmarks give you the same results every time.

[Mrs Beanbag]

Use RS to define your data structures, then put a single dcb.b in the BSS hunk with the total byte size.

Then one can do

__RS set ((__RS-1)|3)+1

or somesuch

[Photon]

The basic problem is that CNOP is just a way of aligning data, a replacement for modifying "*" (program counter) as allowed by older assemblers. In a BSS section, it should become a DS and in code or data sections, it should become a DC of the appropriate size. Or the assembler should just skip a few bytes in memory in all cases, it should not matter to the developer.

It's a silly directive name, anyway. There's no real condition and certainly no CPU NOP instruction involved anywhere.

[Photon]

Moved to the Assembler forums where it should be.