English Amiga Board


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

 
 
Thread Tools
Old 03 May 2020, 21:38   #21
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by Thomas Richter View Post
While I am not a mot engineer, I believe I understand. PC relative addressing is supposed to address the "text" section of the program, and this section is supposed to contain constant, non-modifyable data only. For that reason, pc-relative addressing is only available as source, not as destionation, i.e. you can move *from* d(PC), but not *to* d(PC) as the latter could modify code in the text section.


tst.x d(PC) is not useful because the data it depends upon is supposed to be constant anyhow, so the test is meaningless as the result is always the same.


btst dx,d(PC) is, however, useful to test whether data register dx is contained in a pre-defined 8-bit set. The address contains a constant bitmask that contains a 1 for all those values of dx that are in the set.


btst #x,d(PC) is not really useful in this logic, though, the result cannot change and could be pre-computed, and thus there is no need for the test.
hmm, you have not convinced me

I simply think that the engineers realized that they had mistakenly overlooked this possibility and corrected in 020+
(so much that they added tst.x (d,pc), but not move.x <ea>,(d,pc) to avoid SMC and constant data tampering).

Having variable data near the PC is very convenient and in any case you can use move.x d(pc),Dx on 000 instead of tst.x if you have a spare register and it's absolutely lawful..

EDIT: ah! and about btst dx,d(PC) and a pre-defined bit set.. btst dx,#d exists, even if it's one of the strangest instructions in the set

Last edited by ross; 03 May 2020 at 22:12.
ross is offline  
Old 03 May 2020, 22:54   #22
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,660
Didn't tst execute a read-modify-write cycle on 68000? This could be another reason that Motorola didn't allow tst d(PC) before 68020. It would write to the text segment.

EDIT: Maybe I confused TST with CLR. Forget it.

Last edited by phx; 03 May 2020 at 22:57. Reason: My memory is weak.
phx is offline  
Old 03 May 2020, 23:42   #23
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by phx View Post
didn't tst execute a read-modify-write cycle on 68000? This could be another reason that motorola didn't allow tst d(pc) before 68020. It would write to the text segment.

Edit: Maybe i confused tst with clr. Forget it.
Only TAS , CLR is read/write but not atomic.
ross is offline  
Old 04 May 2020, 08:49   #24
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,846
Quote:
Originally Posted by ross View Post
EDIT: ah! and about btst dx,d(PC) and a pre-defined bit set.. btst dx,#d exists, even if it's one of the strangest instructions in the set
btst dx,#d is quite useful, i just found it too limited because it can target only bytes...

About btst dx,d(pc) and the constant, it doesn't work very well.
btst #b,d(pc) is allowed even on 68000, but tst.b d(pc,ix) can also target a constant block but isn't allowed.

So tst.x d(pc) on 68000 is either an error (like clr doing read-modify-write) or a failed theory.
meynaf is online now  
Old 23 June 2020, 16:46   #25
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Today I learned something.

I found/thought of a little trick that I have never seen used in any 68k code snippet I've seen, but that is really useful and simple to overcome the lack of
tst.x o(pc)
instruction in bare 68k ISA.
Incredible that I had never thought of it before in all these years! (and I'd be curious if others had ever thought of it )

Situation:
- lack of free data registers (therefore no possibility of use of
move.b o(pc),dx
for testing a flags), or inside an irq routine in which you do not want to save the registers to speed up the situation and need to immediately test a flag.
- flag using a byte in memory, previously set through
st
/
sf
instructions or similar (therefore with content
#%00000000
or
#%11111111
).
- check for
EQ
/
Z


Well a
btst dx,o(pc)
do the job!
Whatever value contains
dx
it's forcibly used as module eight, then a valid check for any bit in
o(pc)
, which is in any case previously properly set.

The only drawback is that it is four cycles slower than a normal
tst.b
under standard conditions, but it's faster than any other solution in situations such as the one described (that is not so rare).

ross is offline  
Old 23 June 2020, 17:19   #26
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,846
Quote:
Originally Posted by ross View Post
Situation:
- lack of free data registers (therefore no possibility of use of
move.b o(pc),dx
for testing a flags), or inside an irq routine in which you do not want to save the registers to speed up the situation and need to immediately test a flag.
- flag using a byte in memory, previously set through
st
/
sf
instructions or similar (therefore with content
#%00000000
or
#%11111111
).
- check for
EQ
/
Z
In an interrupt i would use simple
tst.b addr
.
In the main code i would use a base reg, such as
tst.b d(a5)
.
This has the advantage to work with the
st
/
sf
instructions themselves as well.
Perhaps it's the reason why you've never seen this in actual code (neither do i, btw)


Quote:
Originally Posted by ross View Post
The only drawback is that it is four cycles slower than a normal
tst.b
under standard conditions, but it's faster than any other solution in situations such as the one described (that is not so rare).
Another drawback is that anyone disassembling the code will not understand what you're doing
meynaf is online now  
Old 23 June 2020, 17:30   #27
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by meynaf View Post
In an interrupt i would use simple
tst.b addr
.
I need PC relative code only.
And in any case my solution is 2 bytes less

Quote:
In the main code i would use a base reg, such as
tst.b d(a5)
.
This has the advantage to work with the
st
/
sf
instructions themselves as well.
Yep, when I have a base reg. I do the same.
But there are situations where I just can't.. (IRQ code where base reg. is only outside)

Quote:
Another drawback is that anyone disassembling the code will not understand what you're doing
ross is offline  
Old 23 June 2020, 18:29   #28
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,846
Quote:
Originally Posted by ross View Post
I need PC relative code only.
This wasn't listed in the conditions
But if you need PC relative code, then you're gonna have problems any time you write something.


Quote:
Originally Posted by ross View Post
And in any case my solution is 2 bytes less
6 if we count the reloc32 entry. I'm not after code size this much, though...


Quote:
Originally Posted by ross View Post
Yep, when I have a base reg. I do the same.
But there are situations where I just can't.. (IRQ code where base reg. is only outside)
If the IRQ code only accesses this particular variable then ok. But if it accesses several, then the best way is to reload the base reg (and i can't imagine an irq not doing anything else).

In addition, there are conditions that make this not doable.
If code is large enough, then 16-bit offset can't reach the variable.
If the variable is stored in a bss section, then PC-relative mode doesn't apply anymore.

Actually, cases where tst d(pc) is needed seem quite rare. This whole trick is more academic than concrete, right ?
meynaf is online now  
Old 23 June 2020, 18:58   #29
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by meynaf View Post
Actually, cases where tst d(pc) is needed seem quite rare. This whole trick is more academic than concrete, right ?
Probably yes, but.. for some reason (probably because I patch existing code and I don't have control over the base register or it just isn't used and I need tiny pc-relative code) I find myself needing it often

If I develop from scratch the base register is truly irreplaceable but it all depends on what you need and I have already found where to use this trick in two snippet.

ross is offline  
Old 25 June 2020, 15:55   #30
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by meynaf View Post
Another drawback is that anyone disassembling the code will not understand what you're doing
Speaking of non-understandable code:
Code:
pt_E0_command
; cmd E0x (x=0 enable audio filter, x>=1 disable)
; d0 = x

    moveq   #-3,d1
    subq.w  #1,d0
    blo.b   .h
    dc.w    $08f9
.h  dc.w    $c339,$00bf,$e001
    rts
Yes, really dirty but effective
ross is offline  
Old 25 June 2020, 16:42   #31
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,846
Quote:
Originally Posted by ross View Post
Yes, really dirty but effective
It's not really not understandable as the intent is clear, but indeed, very dirty
Reminds me of the cmpi.w trick used by sas/c.
meynaf is online now  
Old 25 June 2020, 16:58   #32
8bitbubsy
Registered User

8bitbubsy's Avatar
 
Join Date: Sep 2009
Location: Norway
Posts: 1,365
Quote:
Originally Posted by ross View Post
Speaking of non-understandable code:
Code:
pt_E0_command
; cmd E0x (x=0 enable audio filter, x>=1 disable)
; d0 = x

    moveq   #-3,d1
    subq.w  #1,d0
    blo.b   .h
    dc.w    $08f9
.h  dc.w    $c339,$00bf,$e001
    rts
Yes, really dirty but effective
Let me guess, this saved 2-4 bytes? That's so hackish it should've been illegal!
8bitbubsy is offline  
Old 25 June 2020, 17:17   #33
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by meynaf View Post
Reminds me of the cmpi.w trick used by sas/c.
Yep, that's what I thought of when I did it


Quote:
Originally Posted by 8bitbubsy View Post
Let me guess, this saved 2-4 bytes? That's so hackish it should've been illegal!
Theoretically in motorola manuals module 8 is guaranteed for the second word of bxxx instructions.
But you never know that an extension to ISA makes it illegal (so impossible..)

ross is offline  
Old 25 June 2020, 17:23   #34
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 47
Posts: 3,846
If you're patching code and it doesn't fit otherwise, then it's acceptable.
If you're coding in a ROM and space is extremely limited, then it's acceptable.
Otherwise, forbidden. Coder license revoked !

Makes me wonder if there are general tricks that can be used to set/clr a single bit from a condition (with short and efficient code, that is).
meynaf is online now  
Old 25 June 2020, 18:18   #35
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,584
Quote:
Originally Posted by meynaf View Post
If you're patching code and it doesn't fit otherwise, then it's acceptable.
If you're coding in a ROM and space is extremely limited, then it's acceptable.
Otherwise, forbidden. Coder license revoked !


Quote:
Makes me wonder if there are general tricks that can be used to set/clr a single bit from a condition (with short and efficient code, that is).
I couldn't think of anything efficient..
To make up for it, 020+ version:
Code:
pt_E0_command
; cmd E0x (x=0 enable, x>=1 disable)
; d0 = x

    lea $bfe001,a0
    subq.w  #1,d0
    shs d0
    bfins   d0,(a0){6:1}
    rts
ross 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
What's my mistake with LEA d8(PC,Dx.L*2),Ax on WinUAE? PeterK Coders. Asm / Hardware 27 04 May 2016 10:24
adda / suba Vs. lea pmc Coders. General 19 04 June 2010 17:28
32bit PC-relative LEA ?? Nut Coders. General 22 18 March 2010 10:56
some beginners question Uncle Micko New to Emulation or Amiga scene 5 20 September 2007 12:32
General asm question Haakon Coders. General 14 15 February 2006 21:42

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 18:46.


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