English Amiga Board


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

 
 
Thread Tools
Old 23 November 2019, 11:41   #1
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
dc.w / dc.l at odd address

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.
meynaf is online now  
Old 23 November 2019, 11:50   #2
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 179
vasm seems to assemble this, in 68000 only mode (-m68000):
Code:
dc.b 0
dc.w 0
Antiriad_UK is offline  
Old 23 November 2019, 11:58   #3
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
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).
meynaf is online now  
Old 23 November 2019, 12:12   #4
Antiriad_UK
OCS forever!

Antiriad_UK's Avatar
 
Join Date: Mar 2019
Location: Birmingham, UK
Posts: 179
Code:
	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?
Antiriad_UK is offline  
Old 23 November 2019, 13:10   #5
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
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.
meynaf is online now  
Old 23 November 2019, 13:17   #6
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,425
Quote:
Originally Posted by meynaf View Post
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

Last edited by ross; 23 November 2019 at 13:25.
ross is offline  
Old 23 November 2019, 14:37   #7
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by ross View Post
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...
meynaf is online now  
Old 23 November 2019, 15:36   #8
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 51
Posts: 1,186
Quote:
Originally Posted by meynaf View Post
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.
Don_Adan is offline  
Old 23 November 2019, 16:21   #9
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 325
Quote:
Originally Posted by meynaf View Post
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.
Quote:
Originally Posted by meynaf View Post
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.
Thomas Richter is offline  
Old 23 November 2019, 16:39   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,569
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.

Last edited by phx; 23 November 2019 at 16:43. Reason: PhxAss
phx is offline  
Old 23 November 2019, 17:18   #11
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by Thomas Richter View Post
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.


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


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


Quote:
Originally Posted by phx View Post
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 :
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 ?
meynaf is online now  
Old 23 November 2019, 22:30   #12
phx
Natteravn

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

Quote:
Even though it strangely accepts misaligned DS directives.
Could be a bug. Or does PhxAss only reject unaligned data which are relocatable labels?

Quote:
Besides, auto-alignment looks dangerous to me. Think about this code :
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(?).
phx is offline  
Old 24 November 2019, 10:45   #13
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by phx View Post
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.
meynaf is online now  
Old 24 November 2019, 19:01   #14
freddix
Registered User
freddix's Avatar
 
Join Date: Sep 2006
Location: france, bdr
Age: 44
Posts: 90
if you need alignment, uses 'EVEN' it may work.

for example
dc.b 0,5,3
even
dc.l 0,5
freddix is offline  
Old 24 November 2019, 19:25   #15
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 325
Quote:
Originally Posted by meynaf View Post
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.


Quote:
Originally Posted by meynaf View Post
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.
Thomas Richter is offline  
Old 24 November 2019, 20:08   #16
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by freddix View Post
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.



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


Quote:
Originally Posted by Thomas Richter View Post
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.
meynaf is online now  
Old 25 November 2019, 04:28   #17
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 297
Quote:
Originally Posted by meynaf View Post
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.

Quote:
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!
Bruce Abbott is offline  
Old 25 November 2019, 11:55   #18
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by Bruce Abbott View Post
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.


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


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


Quote:
Originally Posted by Bruce Abbott View Post
4. Amiga OS pads structures, so it's in the finest retro tradition!
I don't care about traditions.


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


Quote:
Originally Posted by Bruce Abbott View Post
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.
meynaf is online now  
Old 26 November 2019, 06:48   #19
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 297
Quote:
Originally Posted by meynaf View Post
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.

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

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

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

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

Quote:
I don't care about traditions.
So why are you programming in machine code on a platform that hasn't changed in 30 years?
Bruce Abbott is offline  
Old 26 November 2019, 10:48   #20
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,667
Quote:
Originally Posted by Bruce Abbott View Post
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.


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


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


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


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


Quote:
Originally Posted by Bruce Abbott View Post
I am looking at them. Take AmigaBASIC for example. Whoever coded it should have been shot.
This is an extreme case


Quote:
Originally Posted by Bruce Abbott View Post
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.
meynaf is online now  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
uncrunch same address of source Giants Coders. General 18 24 October 2018 18:57
Address register expected Nightfox Coders. Asm / Hardware 4 12 August 2016 12:51
How to show IP Address? AGS support.Apps 18 08 May 2014 22:05
DevPac and Absolute Address h0ffman Coders. General 2 14 January 2011 16:32
NAT address -Rob- support.Other 7 07 April 2008 01:06

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 10:38.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.10219 seconds with 15 queries