English Amiga Board


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

 
 
Thread Tools
Old 02 May 2020, 21:41   #1
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Beginners ASM Question LEA

Hi. Just learning M68k ASM, and I have a question. Probbably gets asked all the time regarding LEA nmonic.

Example Code

Code:
Start   lea data,A0
          move.l,(A0)
          rts

data   EVEN
         dc.l $ABCDABCD
This peice of code does exactly what it says on the tin, but I was wondering,
for the code to be truly relocatable, the lea should be calculated as a realative offset, so maybe lea (d16,PC),A0 would be preferable?
trouble is, when I substitute it with

Code:
START     lea (data,PC),A0
I get the compile error 'missing close bracket at line ... '
I do realise that the value of START would be a Long Word, and the offset should be a Word, but I had assumed the assembler would have calulated the offset value?
What would the correct way to do what I'm trying? Im just playing around, to get familiar with the instuction mnonic set at the moment. I realise, when reading the motorola referance gude, that lea is designed to be used with working with data structures, but I'm starting simple

Regards
Dave
digitalwarfare is offline  
Old 02 May 2020, 21:47   #2
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,185
First try:

lea data(PC),A0

Then you don't need EVEN directive since data is after some code. And if you had to put EVEN, put it BEFORE data or that would make data point to a wrong value.

Also move.l,(A0) makes no sense. I suppose it's a typo
jotd is offline  
Old 02 May 2020, 22:02   #3
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 1,831
What jotd said.
mcgeezer is offline  
Old 02 May 2020, 22:16   #4
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Sorry, Yes, Typo

Code reads

move.l D0,(A0)
digitalwarfare is offline  
Old 02 May 2020, 22:56   #5
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Quote:
Originally Posted by jotd View Post
First try:

lea data(PC),A0

Then you don't need EVEN directive since data is after some code. And if you had to put EVEN, put it BEFORE data or that would make data point to a wrong value.

Also move.l,(A0) makes no sense. I suppose it's a typo
That Works great. However, It is making me wonder if Im not reading the Referance manual correctly? I know it sound like im not accepting what is being said, and moving on, but I need to know the very basics... Including reading the manual correctly.

the manual says : Operation : LEA <ea>,An
and the addressing mode table says : (d16,PC)

I know this may sound like me being pickey, but unless I know whats going on, I won't learn anything.
By the way I'm using DevPac 3.04, if that makes any difference

Thankyou for your patiance
Dave

Last edited by digitalwarfare; 02 May 2020 at 23:02.
digitalwarfare is offline  
Old 02 May 2020, 23:07   #6
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,185
lea <ea>,An isn't position-independent. This normally isn't an issue since assemblers produce relocation tables. But if you want to copy your code somewhere else and use it, you can't do that if <ea> is a label of your program.

Also PC-relative code is shorter in memory when you can do it.

but if you want to load hardware base you have to use non-PC:

lea $dff000,a0
jotd is offline  
Old 02 May 2020, 23:47   #7
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Quote:
Originally Posted by jotd View Post
lea <ea>,An isn't position-independent. This normally isn't an issue since assemblers produce relocation tables. But if you want to copy your code somewhere else and use it, you can't do that if <ea> is a label of your program.

Also PC-relative code is shorter in memory when you can do it.

but if you want to load hardware base you have to use non-PC:

lea $dff000,a0
Thats Cool.Thankyou, but that has now raised two more questions
I know LEA is a simple command, but the more I know, the better

The LEA data(pc),A0 you gave me works, and the Dissasembler shows it back as that (not the code list view). Happy days. HOWEVER.. when I dissasemle it BY HAND ( ) The memory contents for that are $41FA, Which is the LEA code. (%0100000111111010), the syntax by the book is indeed LEA (D16,PC),A0 . As your code works and compiles, it is correct. that would mean, that the error is EITHER the book, or the way Im reading it. I must assume the error is me reading it. If im reading it wrong, Im learning wrong. I need to know what Im reading wrong, but I just cant see it!!

Second question.. What is the correct way to do this in position independant way?

Edit :
Ignore Second question... I eximned the object code in memory, and Lea did calculate the displacement value correctly, in the word following $41FA (LEA), so that would make the object code relocatable

Thanks
Dave

Last edited by digitalwarfare; 03 May 2020 at 00:14.
digitalwarfare is offline  
Old 03 May 2020, 00:13   #8
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,185
for position independent: use lea data(pc),a0 form. data has to be not too far (+$7FFF/$8000) or assembler will complain (or mask and create buggy code!)


When disassembling, the 2 first bytes are the opcode. Followed by arguments. The opcode is different between a LEA with PC or LEA absolute.

The mnemonic doesn't give a good indication about what the opcode is going to be when there are arguments.
jotd is offline  
Old 03 May 2020, 00:33   #9
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Quote:
Originally Posted by jotd View Post
for position independent: use lea data(pc),a0 form. data has to be not too far (+$7FFF/$8000) or assembler will complain (or mask and create buggy code!)


When disassembling, the 2 first bytes are the opcode. Followed by arguments. The opcode is different between a LEA with PC or LEA absolute.

The mnemonic doesn't give a good indication about what the opcode is going to be when there are arguments.
Yes. I understand that the dispacement is only 1 Word ( which would only allow a range of 32k either side of the PC ).
Im not sure if im explaining myself correctly. I used the Syntax you gave me, which is great, but when I decode the opcode, and go by the syntax in the book, it looks different for the same command

LEA data(PC),A0 assembles into $41FA000A (the data in my code is infact located 10 Bytes ahead of the PC at that point)

When I dissasmble by hand and put the binary into the table (with pen and paper) it comes back as LEA (d16,PC),A0

As Im using this book (it is a proper actual book, not a document I downloaded) to use as a programming guide, it must be giving me the incorrect syntax for some commands. It is the actual Motorola Programmers Referance Guide. Thats what prompted me to ask in the first place, why my code wouldnt compile in the first place. Your syntax, which compiles fine isn't even mentioned, but decompiled SHOULD match the book. Is this book inacurate?

Picture of what Im reading \/
Click image for larger version

Name:	20200502_232846.jpg
Views:	61
Size:	976.3 KB
ID:	67161

Last edited by digitalwarfare; 03 May 2020 at 01:03.
digitalwarfare is offline  
Old 03 May 2020, 01:26   #10
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,617
Right, the book is correct but its not displaying how the majority of 68000 assemblers make that instruction look.

So in the book it says essentially lea (D16,PC) and then whatever address register afterwards.

I guess this must be a pretty old book.

So, as JOTD said, if you want to address something that is PC relative, the max size is $7FFF+0 forward or backwards of the current instruction you are executing.

$7FFF +0 is the maximum 16bit word that instruction can access, so what I think the book is saying is the D16 refers to the max bit size that can be accessed by that instruction.

In code usually it would look like this:

LEA CODE(PC),a0
NOP
NOP
NOP
CODE:
RTS

In the encoding of the instruction you would have $41FA as the opcode to denote LEA/PC relative/Accessing A0, and then followed by a word with a max size of $7FFF + 0

Every single assembler i've ever seen or used, would display that instruction as above, not as the book has it listed, I just don't think the book is very clear how that instruction is assembled.
Galahad/FLT is offline  
Old 03 May 2020, 01:29   #11
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,670
The reference manual is using the new syntax:
(d,PC)
, which was introduced together with the 68020. The old 68000 syntax is
d(PC)
, but both mean exactly the same.

Many assemblers support both forms. I'm surprised that Devpac3 doesn't. Maybe there is an option?
phx is offline  
Old 03 May 2020, 01:44   #12
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,628
Yes, an option or a machine directive, like:

Code:
	machine	mc68020

Start	lea (data,pc),a0
	move.l	(A0),d0
	rts

data	dc.l $ABCDABCD
ross is offline  
Old 03 May 2020, 01:48   #13
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
Quote:
Originally Posted by phx View Post
The reference manual is using the new syntax:
(d,PC)
, which was introduced together with the 68020. The old 68000 syntax is
d(PC)
, but both mean exactly the same.

Many assemblers support both forms. I'm surprised that Devpac3 doesn't. Maybe there is an option?
Brilliant. just before I checked for replies, I managed to find a copy of the Devpac Manual. It mentions New 68020 Syntax for Old Modes. I'm looking currently to see if there is a setting.
I was worried there was somthing fundamental I was doing wrong.
I wasnt being picky on purpose, but I know its important to get the very basics sorted, before doing anything remotly complex. Thats how I was taught Z80, many years ago.
Thankyou everyone for your help. :-D Im sure Ill have many more questions. please forgive me if they seem to be 'simple' questions.
Regards
Dave

Edit: I have found the setting. If I set the the targate to 68020, It compiles in both ways, just fine. Yes, The book is quite old, but I think its the latest one, as it includes the 060

Last edited by digitalwarfare; 03 May 2020 at 01:55.
digitalwarfare is offline  
Old 03 May 2020, 09:12   #14
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,185
the syntax may be different, but it generates the exact same code as lea data(pc),a0. I don't recommend setting 68020 directive if the final target may be a 68000. That means that you can use 68020+ only instructions by mistake and it will crash on a 68000.
jotd is offline  
Old 03 May 2020, 11:04   #15
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,628
Quote:
Originally Posted by jotd View Post
I don't recommend setting 68020 directive if the final target may be a 68000. That means that you can use 68020+ only instructions by mistake and it will crash on a 68000.
I totally agree.

An instruction with addressing mode relative to pc that I tend to use (and that does not exist on bare 000) is
tst d(pc)
*.
With this machine directive or option, non-working code would be generated.
So ok that there is a possibility, but to be used with caution and remember what can or cannot be used.

Or use a different assembler


*Original Motorola engineers should explain to me why
btst #x/Dx,d(pc)
instead is usable..
ross is offline  
Old 03 May 2020, 11:22   #16
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,185
and btst pc relative is pretty difficult to use, since it's .B only. So if d is a 32 bit int you have to add +1, +2, +3 depending on the bit position...
jotd is offline  
Old 03 May 2020, 18:56   #17
digitalwarfare
Registered User

 
Join Date: Jan 2020
Location: Farnham
Posts: 15
So, If my targate IS 68000, I should NOT say targate is 020+ just so I can use the notation (Mem,PC) and use Mem(PC). Thats what I should take away from this? Ie.. this is good programming techniques

Now for code optimisation...

I assume its faster to use add within registers, than direct to memory locations?

Also.. faster still using addq if possible (Immidiate value of 1 to 8)

ie
addq #$01,D3
is faster than
addq #$01,(A3)

and the speed effects are cumalative in loops? The manual doesnt give timings for instructions
digitalwarfare is offline  
Old 03 May 2020, 19:21   #18
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 46
Posts: 7,617
Quote:
Originally Posted by digitalwarfare View Post
So, If my targate IS 68000, I should NOT say targate is 020+ just so I can use the notation (Mem,PC) and use Mem(PC). Thats what I should take away from this? Ie.. this is good programming techniques

Now for code optimisation...

I assume its faster to use add within registers, than direct to memory locations?

Also.. faster still using addq if possible (Immidiate value of 1 to 8)

ie
addq #$01,D3
is faster than
addq #$01,(A3)

and the speed effects are cumalative in loops? The manual doesnt give timings for instructions
In the case of 68020+ notations, there is little point in using them when the alternative of the notation for 68000 will work on everything.

The most important thing to remember is if you're not specifically targeting 68020+ is to not use instructions that cannot be used natively on 68000.
Galahad/FLT is offline  
Old 03 May 2020, 19:45   #19
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 2,628
Quote:
Originally Posted by digitalwarfare View Post
Now for code optimisation...
...
The manual doesnt give timings for instructions
For 68000 instructions timing see here:
http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML
or here:
https://wiki.neogeodev.org/index.php...ctions_timings

Do not neglect the values in brackets, the Amiga is a machine with intense DMA activity, and when code/data are in chip memory, limiting access to the bus is always a good thing.

Have fun
ross is offline  
Old 03 May 2020, 20:52   #20
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 477
Quote:
Originally Posted by ross View Post
*Original Motorola engineers should explain to me why
btst #x/Dx,d(pc)
instead is usable..

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.
Thomas Richter 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 04:02.


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