dc.w / dc.l at odd address

[meynaf]

As title says.
I wonder if there exists some assembler which can accept that. At least phxass doesn't.
Because even though 68000 has these alignment restrictions, 68020+ doesn't. And i sometimes need to pack structures (or port code from another cpu).

In addition, i wonder if AmigaDOS would accept doing a relocation at an odd address. At least, there is nothing in hunk format itself that forbids this.

[Antiriad_UK]

vasm seems to assemble this, in 68000 only mode (-m68000):

dc.b 0
dc.w 0

[meynaf]

With a value of 0 it is like ds directive, and ds.w / ds.l is accepted regardless of alignment (and would be easy to handle with ds.b anyway).

[Antiriad_UK]

	dc.b 5
	dc.w 10

Works too. But i've not disassembled to check. My default assemble params include -m68000 -phxass so would ass-u-me that phxass would be the same?

[meynaf]

The above is rejected by phxass (-> error 40 : Word at odd address).
It may be that vasm does auto-align.
To see this, just do hex dump of the assembled file.

[ross]

Originally Posted by meynaf

In addition, i wonder if AmigaDOS would accept doing a relocation at an odd address. At least, there is nothing in hunk format itself that forbids this.

Unfortunately not.

KS1.x support it on bare 68k.
In KS2.0+ a 020+ is required.

Probably some optimization done in later hunk loader that breaked this 'feature'.

EDIT: in fact this could also be considered as a yes if you are only interested in 020+ code

[meynaf]

Originally Posted by ross

EDIT: in fact this could also be considered as a yes if you are only interested in 020+ code

This is the case. Bare 68000 wouldn't be able to access this data anyway, would it ?

Now the problem is to find an assembler that will generate them...

[Don_Adan]

Originally Posted by meynaf

This is the case. Bare 68000 wouldn't be able to access this data anyway, would it ?

Now the problem is to find an assembler that will generate them...

From my memory only some Titus games used dc.w offsets at odd address on 68000 for some music data. It works something like this:

Lea data,A4
Move.b (a0)+,d0
Lsl.w #8,d0
Move.b (a0)+,d0
Lea (a4,d0.w),a0
....

Data
Dc.b 1
Dc.w start1-Data
Start1
Dc.b 6
...
Because Resource and Amiga assemblers dont like especially dc.w/dc.l at odd addreseses, i must use different way to creating custom modules from these Titan games. Original code was perhaps generated with strange C compiler, i think. This compiler created also movem.l ,-(sp) and movem.l (sp)+, opcodes too. Most assemblers dont handle these opcodes too.

[Thomas Richter]

Originally Posted by meynaf

I wonder if there exists some assembler which can accept that.

Not that I know of, but every decent assembler should allow you to create a macro that converts a word-sized argument to two dc.b directives.

Originally Posted by meynaf

In addition, i wonder if AmigaDOS would accept doing a relocation at an odd address.

No. The segment loader would crash, at least on a 68K.

[phx]

Yes, I can confirm that I decided to allow unaligned data by default in vasm. You can enable auto-alignment with the -align option (which vasm also does in -devpac compatibility mode).

I know that LoadSeg() doesn't allow unaligned relocs, but vasm is not restricted to AmigaOS. Even on Amiga you could write absolute code with ORG and write it as a raw binary.

EDIT: Then it's probably a bug that -phxass compatibility doesn't include the -align option. Will fix that.

[meynaf]

Originally Posted by Thomas Richter

Not that I know of, but every decent assembler should allow you to create a macro that converts a word-sized argument to two dc.b directives.

I know and this is what i am currently using, but this sometimes fails. It works fine with literals, but it's dubious with offsets (adr1-adr2), and it's just impossible with direct 32-bit addresses for which a reloc is necessary. Think about doing some sort of a script using byte commands which sometimes requires a memory address as parameter.

Originally Posted by Thomas Richter

No. The segment loader would crash, at least on a 68K.

Of course but the target is 68020+ so there is no reason it would crash there.

Originally Posted by phx

Yes, I can confirm that I decided to allow unaligned data by default in vasm. You can enable auto-alignment with the -align option (which vasm also does in -devpac compatibility mode).

Good thing to know.

Originally Posted by phx

EDIT: Then it's probably a bug that -phxass compatibility doesn't include the -align option. Will fix that.

Why ? Phxass doesn't do auto-align. Instead it rejects misaligned data, which is (usually) a useful feature. Even though it strangely accepts misaligned DS directives.

Besides, auto-alignment looks dangerous to me. Think about this code :

 dc.b 1
label
 dc.w 2

If the label is on a different line, then it will probably not be adjusted, will it ?

[phx]

Originally Posted by meynaf

Phxass doesn't do auto-align. Instead it rejects misaligned data, which is (usually) a useful feature.

Hmm, then my previous setting was correct. Seems I have to make some tests with PhxAss first. From a quick glance into the source I didn't see that alignment check. But PhxAss can also do auto-alignment as an option.

Even though it strangely accepts misaligned DS directives.

Could be a bug. Or does PhxAss only reject unaligned data which are relocatable labels?

Besides, auto-alignment looks dangerous to me. Think about this code :

 dc.b 1
label
 dc.w 2

If the label is on a different line, then it will probably not be adjusted, will it ?

No. That would certainly be wrong. I remember there was even a thread about it, some years ago. As a result I decided that a label is only auto-aligned when it is on the same line as the directive to align:

label: dc.w 2

IIRC, Devpac does the same(?).

[meynaf]

Originally Posted by phx

Could be a bug. Or does PhxAss only reject unaligned data which are relocatable labels?

It seems intentional because blk/dcb directives are accepted if no value is specified or if the value is 0.
Else all unaligned data is rejected, regardless of what it is.

[freddix]

if you need alignment, uses 'EVEN' it may work.

for example
dc.b 0,5,3
even
dc.l 0,5

[Thomas Richter]

Originally Posted by meynaf

I know and this is what i am currently using, but this sometimes fails. It works fine with literals, but it's dubious with offsets (adr1-adr2), and it's just impossible with direct 32-bit addresses for which a reloc is necessary.

You cannot use labels there indeed. This is a restriction of the Amiga hunk format which does not provide a mechanism to identify "high byte of a 16 bit offset". Thus, something like "dc.b address >> 8" cannot work. The format has provisions to indicate 16 and 8 bit relatives, but this is as good as it gets.

Originally Posted by meynaf

Of course but the target is 68020+ so there is no reason it would crash there.

Well, let's put it like this: "In principle" you can put an odd byte offet into the hunk-reloc section - but frankly: Attempting to load such a binary on a 68000 and getting a software failure before the program can identify to the user as requiring a 68020+ is probably not such a nice idea.

[meynaf]

Originally Posted by freddix

if you need alignment, uses 'EVEN' it may work.

for example
dc.b 0,5,3
even
dc.l 0,5

Guess what, i knew this.
But here this is precisely what i'm trying to avoid. Why the heck should i add wasteful padding where the cpu doesn't need it.

Originally Posted by Thomas Richter

You cannot use labels there indeed. This is a restriction of the Amiga hunk format which does not provide a mechanism to identify "high byte of a 16 bit offset". Thus, something like "dc.b address >> 8" cannot work. The format has provisions to indicate 16 and 8 bit relatives, but this is as good as it gets.

Such a mechanism doesn't look very useful...
Anyway, assemblers themselves already don't like doing computations on offsets.

Originally Posted by Thomas Richter

Well, let's put it like this: "In principle" you can put an odd byte offet into the hunk-reloc section - but frankly: Attempting to load such a binary on a 68000 and getting a software failure before the program can identify to the user as requiring a 68020+ is probably not such a nice idea.

Not a nice idea indeed i suppose, but if the OS can't protect itself against unsupported things (that are easy to check), not my fault.

[Bruce Abbott]

Originally Posted by meynaf

Guess what, i knew this.
But here this is precisely what i'm trying to avoid. Why the heck should i add wasteful padding where the cpu doesn't need it.

Several reasons.

1. Not padding is less efficient because it takes two memory cycles to access a word on a byte boundary.

2. You've got plenty of memory. Do you micromanage all your code to save every last byte? I bet you don't.

3. Someone might have a fast 68000 and they won't be able to run your code if it's not padded (same reason you shouldn't use any 68020 instructions unless absolutely necessary).

4. Amiga OS pads structures, so it's in the finest retro tradition!


Half the things assembly language programmers do to make their code 'less wasteful' are of dubious worth or even counterproductive.

if the OS can't protect itself against unsupported things (that are easy to check), not my fault.

It is your fault if you are the one making 'unsupported things'.

Yeah, I know - it's 2019 and devices are supposed to handle whatever crap is thrown at them these days. But that's one reason we still use our trusting old Amigas, from a time when people acted responsibly and vandalism wasn't tolerated. Amiga OS gets a lot of its speed by not checking things. And it shouldn't have to. You are supposed to write code that doesn't crash the OS!

[meynaf]

Originally Posted by Bruce Abbott

1. Not padding is less efficient because it takes two memory cycles to access a word on a byte boundary.

Not if it is located in the middle of a longword. Actually, out of 4 possible alignment cases, only one will require two accesses.

And as the exact same code has to handle both cases (it can't know if the data is currently aligned or not), it is a lot faster than having to realign before making the memory access.

Originally Posted by Bruce Abbott

2. You've got plenty of memory. Do you micromanage all your code to save every last byte? I bet you don't.

Sure i don't micromanage all single bytes. But would you really accept to waste kilobytes to padding ?

Originally Posted by Bruce Abbott

3. Someone might have a fast 68000 and they won't be able to run your code if it's not padded (same reason you shouldn't use any 68020 instructions unless absolutely necessary).

I use 68020 things all the time. 68000 is a PITA (in comparison).

Originally Posted by Bruce Abbott

4. Amiga OS pads structures, so it's in the finest retro tradition!

I don't care about traditions.

Originally Posted by Bruce Abbott

Half the things assembly language programmers do to make their code 'less wasteful' are of dubious worth or even counterproductive.

Agreed. But as long as it is fun to do, why not ?

Originally Posted by Bruce Abbott

It is your fault if you are the one making 'unsupported things'.

Yeah, I know - it's 2019 and devices are supposed to handle whatever crap is thrown at them these days. But that's one reason we still use our trusting old Amigas, from a time when people acted responsibly and vandalism wasn't tolerated. Amiga OS gets a lot of its speed by not checking things. And it shouldn't have to. You are supposed to write code that doesn't crash the OS!

My code can't crash the OS before even being called...
And the users aren't supposed to run on 68000 something that's explicitly documented as requiring 68020+.
It's not worse than all these programs using the fpu and crashing 8000000F without a warning. Or these who work on 68000 and fail on anything else.

Checking the reloc alignment wouldn't make the OS significantly slower, btw.

[Bruce Abbott]

Originally Posted by meynaf

Not if it is located in the middle of a longword. Actually, out of 4 possible alignment cases, only one will require two accesses.

Still less efficient than being word-aligned. And a longword will be misaligned in 3 out of 4 cases.

And as the exact same code has to handle both cases (it can't know if the data is currently aligned or not), it is a lot faster than having to realign before making the memory access.

Sounds like a fairly specific application. Why can't the alignment be set in advance?

Sure i don't micromanage all single bytes. But would you really accept to waste kilobytes to padding ?

I don't care about a few kilobytes. Modern programs 'waste' hundreds of kilobytes without even thinking about it. But if I had some data that wasted a lot of space for alignment (or any other reason) I would consider a more efficient format.

I use 68020 things all the time. 68000 is a PITA (in comparison).

There are specific cases where 020 code is a bit more efficient and saves some typing, but the vast majority of '68020 optimized' programs I have analyzed had very few 68020 instructions in them. I haven't felt the need to use it my own code. I might if I was coding something specifically for the A1200 and wanted the fastest speed possible - but then I have a 50MHz 030 so speed isn't usually an issue for me (a bigger problem is considering other users with slower machines).

It's not worse than all these programs using the fpu and crashing 8000000F without a warning. Or these who work on 68000 and fail on anything else.

I am looking at them. Take AmigaBASIC for example. Whoever coded it should have been shot.

I don't care about traditions.

So why are you programming in machine code on a platform that hasn't changed in 30 years?

[meynaf]

Originally Posted by Bruce Abbott

Still less efficient than being word-aligned. And a longword will be misaligned in 3 out of 4 cases.

Right, but as said, doing the alignment would force the code to do the same so it's not an option.

Originally Posted by Bruce Abbott

Sounds like a fairly specific application. Why can't the alignment be set in advance?

Because it's about (semi-)automatic port of code that doesn't care about alignment at all.

Originally Posted by Bruce Abbott

I don't care about a few kilobytes. Modern programs 'waste' hundreds of kilobytes without even thinking about it.

It's not a reason to do the same.

Originally Posted by Bruce Abbott

But if I had some data that wasted a lot of space for alignment (or any other reason) I would consider a more efficient format.

When you have to mix data of different sizes in the same stream there is little choice.

Originally Posted by Bruce Abbott

There are specific cases where 020 code is a bit more efficient and saves some typing, but the vast majority of '68020 optimized' programs I have analyzed had very few 68020 instructions in them. I haven't felt the need to use it my own code. I might if I was coding something specifically for the A1200 and wanted the fastest speed possible - but then I have a 50MHz 030 so speed isn't usually an issue for me (a bigger problem is considering other users with slower machines).

The most often used is the scaled index - not an instruction by itself. Then comes the ability to access misaligned data - and this isn't necessarily seen in the source. So if you just count 68020 instructions you may be missing something.

Originally Posted by Bruce Abbott

I am looking at them. Take AmigaBASIC for example. Whoever coded it should have been shot.

This is an extreme case

Originally Posted by Bruce Abbott

So why are you programming in machine code on a platform that hasn't changed in 30 years?

Precisely because of this ! It is stable (specs don't change every day). A working routine is a routine for life.
And it's fun to code on.