English Amiga Board


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

 
 
Thread Tools
Old 06 January 2020, 09:49   #21
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,664
We're seeing here a shortcoming of 68k asm syntax.
If instead of 2(pc) we could have writen something like (pc+2) then it would have ceased to be ambiguous - we would have been able to write either label(pc) or (pc+val).
But it's too late to change this (i think).

Anyway, it doesn't seem to be of any use.
For new code, it's easy to avoid by using * or labels.
For old code, maybe it would be better to fix the source rather than the assembler...
meynaf is offline  
Old 06 January 2020, 11:31   #22
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 447
Quote:
Originally Posted by phx View Post
What code would you expect to be generated, when writing
Code:
        section code,code
        lea     2(pc),a0
        rts
And what code would you expect when writing
Code:
        org     $0
        lea     2(pc),a0
        rts
?

Many assemblers (Devpac doesn't) would encode the offset of 2 directly into the instruction, making the LEA effectively load the address of RTS. Is this an often used feature?

I'm currently working on improving the absolute ORG-mode in vasm and the second example gives me headaches, because labels and numbers are both becoming absolute. (The advantage is that any arithmetic operation will be allowed with labels.)

my expectation is, that the encoded offset is handled as in bcc/bsr.
Code:
    X(pc)

if X is a number, that number is used without conversion. Thus
Code:
    lea     2(pc),a0
will point to rts, since when the offset is applied the first to bytes are already read - same as in bcc/bsr.


if X is a label, the compiler calculates the number to be used.


if X is a EQU <number> then X is a number, see above.


There is no need for an additional syntax - just keep it simple - as it is.

EDIT: ORG mode is irrelevant for pc relative insns.
bebbo is offline  
Old 06 January 2020, 12:08   #23
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,042
Quote:
Originally Posted by kalms View Post
i expect that blah in blah(pc) or (blah,pc) to be a reference to a symbol or an absolute address. I expect it to never be a literal displacement value. If it ever can be a displacement value (like it is in blah(an)) then there is room for misinterpretation. I want the assembler to point out potential mistakes to me.

+1
hooverphonique is offline  
Old 06 January 2020, 14:38   #24
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
Quote:
Originally Posted by Kalms View Post
I want the assembler to point out potential mistakes to me.
This might be an important point.

I agree with most of what Kalms wrote. Except one case:
Quote:
Code:
    section    code,code

    lea    $1234(pc),a0
    rts
... wil generate an error, since $1234 is supposedly a reference to an absolute address
I would rather generate a warning here, which can optionally be switched off. It might be an error (hence the warning), but as it makes no sense to use absolute addresses in PC-relative addressing modes, when using relocatable sections, it can clearly be identified as a direct offset.

I will revert my hacks of the last three days (which even worked in the end), so $1234(pc) in an ORG-section will be calculated as a reference to the absolute address again.
phx is offline  
Old 06 January 2020, 15:41   #25
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,608
Interesting. I've always assumed any displacement value given to be literal, regardless of instruction or addressing mode. Reason being that relative addressing modes don't support the use absolute addresses (I hope this is clear - rewrote that twice ). So for me, the suggested solution would be confusing.

I do get the idea btw, this is only about how I'd "read" such code.

That said... I don't think I've ever used a lea 2(pc),a0 as such. I've always used lea label(pc),a0 in such cases. So I guess it wouldn't change much for me either way.
roondar is offline  
Old 06 January 2020, 16:38   #26
Kalms
Registered User
 
Join Date: Nov 2006
Location: Stockholm, Sweden
Posts: 224
Quote:
Originally Posted by phx View Post
This might be an important point.

I agree with most of what Kalms wrote. Except one case:

Quote:
Originally Posted by kalms
Code:
    section    code,code

    lea    $1234(pc),a0
    rts
... wil generate an error, since $1234 is supposedly a reference to an absolute address
I would rather generate a warning here, which can optionally be switched off. It might be an error (hence the warning), but as it makes no sense to use absolute addresses in PC-relative addressing modes, when using relocatable sections, it can clearly be identified as a direct offset.

I will revert my hacks of the last three days (which even worked in the end), so $1234(pc) in an ORG-section will be calculated as a reference to the absolute address again.
If you do allow $1234(pc) in a relocatable section, then $1234(pc) will assemble in both relocatable and absolute sections, with different interpretations. A line of code which contains "lea 2(pc),a0" will thus assemble but behave differently depending on whether it is placed in a relocatable or an absolute section. I consider this worse than the alternative (to disallow $1234(pc) syntax in relocatable sections).
Kalms is offline  
Old 06 January 2020, 19:21   #27
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
Quote:
Originally Posted by roondar View Post
Reason being that relative addressing modes don't support the use absolute addresses (I hope this is clear - rewrote that twice ).
Er... no?

Quote:
That said... I don't think I've ever used a lea 2(pc),a0 as such.
Neither did I. But it was reported as an error, a few days ago. Maybe it makes sense in jump-table macros, or similar? But even there you could use * or a label with \@.

Quote:
Originally Posted by Kalms View Post
If you do allow $1234(pc) in a relocatable section, then $1234(pc) will assemble in both relocatable and absolute sections, with different interpretations.
Yes. I know. And I don't like that either. But this is how it always worked - at least in relocatable sections. And vasm is not the only assembler treating it as a direct PC offset. Examples: AsmOne, A68k, Barfly-Asm, PhxAss, SNMA. Devpac is an exception. I fear it could break some old sources when I turn it into an error.
phx is offline  
Old 06 January 2020, 22:01   #28
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 297
Quote:
Originally Posted by roondar View Post
Interesting. I've always assumed any displacement value given to be literal, regardless of instruction or addressing mode. Reason being that relative addressing modes don't support the use absolute addresses (I hope this is clear - rewrote that twice ). So for me, the suggested solution would be confusing.
I agree. ProAsm always puts the literal directly into the code, as it should.

Quote:
Originally Posted by phx
vasm is not the only assembler treating it as a direct PC offset. Examples: AsmOne, A68k, Barfly-Asm, PhxAss, SNMA. Devpac is an exception. I fear it could break some old sources when I turn it into an error.
I don't understand why they do that. One of the primary advantages of a symbolic assembler is not having to deal with absolute addresses - even in absolute code. The only case I imagine it might be useful is for patching absolute code where the target address is not included in the source, but then you should be able to simply ORG the address and put a label there.

But if other assemblers do it that way then I guess you have to copy them for compatibility. Perhaps you could have a switch to choose which assembler(s) to be compatible with?
Bruce Abbott is offline  
Old 07 January 2020, 00:47   #29
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,608
Quote:
Originally Posted by phx View Post
Er... no?
What I meant was simply this: on the 68000, the instruction lea 2(pc),a0 always refers to PC+2. Never to address 2 (unless PC=0 ). Similarly, a move 2(a0),d0 always refers to address contained in A0+2.

Hence, when I see a numerical displacement value (as in not a label) in assembly source, I always read it as a literal number that makes the instruction mean "take the value of the register/PC and add this number", not an absolute address.

That said, I do understand how and why you can see it differently. I guess it's my old habit of programming 6502 using a monitor rather than an assembler playing up
roondar is offline  
Old 07 January 2020, 14:57   #30
sparhawk
Registered User

sparhawk's Avatar
 
Join Date: Sep 2019
Location: Essen/Germany
Age: 51
Posts: 244
Quote:
Originally Posted by roondar View Post
That said, I do understand how and why you can see it differently. I guess it's my old habit of programming 6502 using a monitor rather than an assembler playing up

LOL! So I'm not the only one who coded on the 6502/10 with a monitor? Never used an assembler back then, as I didn't even know it existed.
sparhawk is offline  
Old 07 January 2020, 14:59   #31
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 1,608
Yup, that's me. I only used my Final Cartridge III's monitor for coding on the C64
roondar is offline  
Old 07 January 2020, 16:01   #32
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 sparhawk View Post
LOL! So I'm not the only one who coded on the 6502/10 with a monitor? Never used an assembler back then, as I didn't even know it existed.
Quote:
Originally Posted by roondar View Post
Yup, that's me. I only used my Final Cartridge III's monitor for coding on the C64
You are not alone...

Good times
ross is offline  
Old 07 January 2020, 17:33   #33
a/b
Registered User

 
Join Date: Jun 2016
Location: europe
Posts: 174
Quote:
Originally Posted by Bruce Abbott View Post
... But if other assemblers do it that way then I guess you have to copy them for compatibility. Perhaps you could have a switch to choose which assembler(s) to be compatible with?
That's what I suggested earlier, some kind of a flag/switch. Decide what the default is, whether the most common case or what you feel is the correct way of handling it, and then let the users decided how to handle their code.
Additionally, an optional (flag/switch based perhaps) warning would be great so I don't have to wonder if and where are such constructs in this "ocean" of old code I'm assembling. Makes it much easier to review and fix specific lines than review the whole thing or try to debug why it crashes.

re 65xx: monitor49152 on C64 is all I used for hacking around (mostly poke hunting) and coding.
a/b is offline  
Old 08 January 2020, 13:45   #34
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
Quote:
Originally Posted by a/b View Post
That's what I suggested earlier, some kind of a flag/switch.
Ok. You convinced me. I will proably add that. And if the switch enables an error with $1234(pc), it should be set automatically when selecting Devpac-compatibility mode (-devpac).

Quote:
Additionally, an optional (flag/switch based perhaps) warning would be great
Yes. I already decided to do the warning anyway. All warnings in vasm can be disabled (completely or individually).

EDIT: Done. Tomorrow's source snapshot will include all those changes. Attempting to encoding an absolute PC-displacement directly is only done in relocatable sections with a warning now, or not at all with -nodpc or -devpac option.

Last edited by phx; 08 January 2020 at 20:46. Reason: Update.
phx 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
Scanlines offset in WinUAE lbg83430 support.WinUAE 9 05 November 2018 16:27
Calculate offset using labels Beska Coders. Asm / Hardware 7 09 May 2016 19:56
It seem the JIT direct mode is not work in fs-uae. direct mode is important bernd roesch support.FS-UAE 27 20 September 2015 22:44
gfxbase negative offset Asman Coders. System 14 29 May 2015 00:24
Program Counter with Offset - why? Jherek Carnelia Coders. General 26 21 March 2011 11:49

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 02:16.


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