Devpac - CNOP in a BSS Section

[h0ffman]

Trying to assemble the PT315 source in Devpac but the BSS Sections have CNOP 0,4 for aligning the file info blocks. It fails saying..

BSS or OFFSET section cannot contain data

I can't seem to find the correct directive to get it to assemble?

Any ideas?

[Galahad/FLT]

Just use EVEN instead cant you?

[StingRay]

Originally Posted by Galahad/FLT

Just use EVEN instead cant you?

EVEN is not the same as CNOP 0,4!

I can't seem to find the correct directive to get it to assemble?

Easiest "fix": Change the BSS to DATA sections and the CNOP should work.

[matthey]

Originally Posted by h0ffman

Trying to assemble the PT315 source in Devpac but the BSS Sections have CNOP 0,4 for aligning the file info blocks. It fails saying..

BSS or OFFSET section cannot contain data

I can't seem to find the correct directive to get it to assemble?

Any ideas?

You could try vasm with or without -devpac mode. Vasm is mostly compatible with Devpac either way. I believe Frank recently changed vasm from always generating '0' with CNOP to generating NOP with CNOP in code sections. I don't know if this applies to -devpac mode though.

A fairly new version of vasm can be found in vbcc 0.9d.

http://sun.hasenbraten.de/vbcc/

Not only does vasm optimize better than devpac (vasm optimizes branches in both directions for example), but it should be faster. Leffmann timed vasm as being faster than devpac but still 20x slower than PhxAss. My recent tests on the 68060 showed 13x-18x slower than PhxAss so there may be some improvement due to vbcc compiler improvements (Leffmann's tests were done on a 68030 though). I tried a 68060 specific build of vasm with direct FPU use and didn't see any difference in speed. The IEEE fp library using version of vasm in the new vbcc is not so slow for a compiled assembler.

[Don_Adan]

You can use something similar, it works for ASM-One:

 Section Test, BSS

StartBSS
 ds.b 1
 ds.b 2
 ds.b 3
FixBSS
 ds.b (FixBSS-StartBSS+3)/4
AlignedLabel
 ds.b 1000

[StingRay]

This will work too:

PAD4		MACRO
.\@size		= *-\1
.\@size2	= ((.\@size+4)/4)*4
		ds.b	.\@size2-.\@size
		ENDM

data	ds.b	3

	PAD4	data

aligned_data

(quickly adapted my macro to align data to a 512 byte boundary)

[phx]

I am surprised that there is no easy way to align data in a bss section with DevPac. I didn't realize that before.

StingRays solution works with most assemblers.

Another solution would be to start a new section for data objects which need 32-bit or 64-bit alignment. LoadSeg() allocates a new memory block for every section, so 64-bit alignment is guaranteed.

        section fileinfoblock,bss
myfib:

[matthey]

Originally Posted by phx

I am surprised that there is no easy way to align data in a bss section with DevPac. I didn't realize that before.

StingRays solution works with most assemblers.

Another solution would be to start a new section for data objects which need 32-bit or 64-bit alignment. LoadSeg() allocates a new memory block for every section, so 64-bit alignment is guaranteed.

        section fileinfoblock,bss
myfib:

Would it be possible to make vasm align offsets in a BSS section using CNOP? Obviously it would not be possible to insert any data but maybe it could do the offset calculation? It might be a nice feature if it's possible.

[phx]

Originally Posted by matthey

Would it be possible to make vasm align offsets in a BSS section using CNOP?

Did you try it? It always worked, as CNOP pads with zeros in non-code sections.
And as far I can see most assembler behave the same. Except Devpac.

[Galahad/FLT]

Originally Posted by StingRay

EVEN is not the same as CNOP 0,4!




Easiest "fix": Change the BSS to DATA sections and the CNOP should work.

Hmmm, i'm sure I read somewhere in a Hisoft document that if you use an EVEN statement in Devpac as the first line of a data/BSS/whatever section it performs the same.

I've never had to use it, so i've never had to check it.

You however could check your Facebook messages, that would be a good start

[matthey]

Originally Posted by phx

Did you try it? It always worked, as CNOP pads with zeros in non-code sections.
And as far I can see most assembler behave the same. Except Devpac.

I tested vasm in normal and devpac mode and CNOP aligned how I would expect. That means that vasm in devpac mode is not compatible with Devpac but perhaps we could ignore? I didn't find anything in the Devpac 3.0 manual about how to change the CNOP padding data (nothing about what data padding is used either). It would be possible to have an optional 3rd argument with the padding data although I don't know if it would be worth the trouble. I wonder if any other assemblers accept a 3rd argument for CNOP? Vasm does seem to be an option for h0ffman because of the lack of Devpac compatibility at least .

[StingRay]

Originally Posted by Galahad/FLT

Hmmm, i'm sure I read somewhere in a Hisoft document that if you use an EVEN statement in Devpac as the first line of a data/BSS/whatever section it performs the same.

I pretty much doubt that as EVEN = CNOP 0,2!

[phx]

Originally Posted by matthey

CNOP aligned how I would expect. That means that vasm in devpac mode is not compatible with Devpac but perhaps we could ignore?

Yes, I think so. It makes no sense to support that.
While developing vasm I always saw Devpac as the reference assembler. But now I'm a bit disappointed.

I wonder if any other assemblers accept a 3rd argument for CNOP?

No. Some assemblers have CNUL (e.g. snma), which pads with zeros, while CNOP pads with NOP instructions when possible.


Besides CNOP it also makes sense to pad code hunks with NOP, when their length is not a multiple of four. Unfortunately Amiga assemblers show a very different behaviour:

Assembler   | CNOP NOP padding | code hunk NOP padding
------------------------------------------------------
A68k        | yes              | yes
AsmOne      | no               | no
Barfly      | no               | yes
Devpac      | no               | no
PhxAss      | yes              | yes
vasm        | yes (since 1.7c) | yes (since 1.7c)

Strange that Devpac doesn't pad CNOP 0,4 with NOP, although it has problems with it in a BSS section. Make no sense at all...

[Galahad/FLT]

Originally Posted by StingRay

I pretty much doubt that as EVEN = CNOP 0,2!

Probably wasnt an official Hisoft document then.

CAN YOU RESPOND TO YOUR MESSAGES ON FACEBOOK THAT YOUVR READ AND NOT RESPONDED TO.....CAN YOU DO THAT MATE? THIS YEAR IS PREFERABLE, THIS WEEK WOULD BE BETTER......T O D A Y WOULD BE POLITE.


CAN YOU DO THAT MATE??????????????????????????????????????????????????

[IFW]

It's been a very long time since I did this, but... the original system uses BCPL pointers and convert between them by shifting left and right by 2 when accessing sections.
Therefore, each section is guaranteed to start at an address that is an integral multiple of 4.

[IFW]

Also I am positive we used alignment in our games, which were all compiled using DevPac, but would have to dig up the sources to find out what the syntax exactly was. I might try if anything else fails...

[IFW]

As far as I can see from some random source is that I used a section where 4 byte alignment was needed, the first data there is certainly starting at a 4 byte alignment. Then ds.b could be added with modulo 4 of the difference between known reference points to make sure that the next label starts at an integral multiple of 4.
Since the expression evaluator is particularly dumb by today's standards, you have to write something like this:

section bss

start ds.b 0

junk ds.b <your data>

pad ds.b ((pad-start+3)/4*4)-(pad-start)

align4 ds.b <your 4 byte aligned data>

You can probably make this a macro with a local label in place of "pad" to make the code actually readable

[IFW]

And CNOP works just as well in 3.18

section bss

junk ds.b <your data>

align cnop 0,4

data at the label "align" is 4 byte aligned.

[hooverphonique]

would a section not always start on an 8-byte boundary? or do some linkers combine sections, so this could be voided?

[phx]

Originally Posted by IFW

And CNOP works just as well in 3.18

section bss

junk ds.b <your data>

align cnop 0,4

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.

Originally Posted by hooverphonique

would a section not always start on an 8-byte boundary? or do some linkers combine sections, so this could be voided?

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.