John,
Purely from a software / compiler standpoint, a C compiler treats the CPU32 as a 32-bit address machine. So, you will see instructions that use the full 32-bits of addressing.
In reality, only 24-bits of address are implemented on the CPU32. Also, there are only 24 address line comparators that compare the address on the address bus with the contents of the Base Address Registers used with the chip select lines.
So, to the CPU32, the physical address $FFFF 1234 is treated exactly like the physical address $00FF 1234.
Address lines A24 thru A31 (and anything associated with them) just don't physically exist.
Now, one has to be careful here because there is a CPU32+ that implements the entire bus. So, it is always a good thing when writing CPU32 code to make sure that the compiler limits it's address calculations to 24-bits just in case the code will ever need to be transported to a bigger machine.
Regards,
Charlie
-----Original Message-----
From: John Mermigis [mailto:johnmerm@...]
Sent: Wednesday, March 05, 2003 5:03 AM
To: 68300@yahoogroups.com
Subject: RE: [68300] Re: Theoretical questions
First of all thank you all Guys for your interest in my question
Actually, I did mention that this was a purely theoretical question, I have already solved the problem using the folowing syntax
lea A2,_BlaBla
move.l (A2),A1
using this I (and everyone) can overcome the Bus error exception, but I still I want to know it all
Now for the 24 vs 32 bit issue. Since I don't really know how indirect access works, I suppose that when Assembler (I didn't use C at this point neither inline assembly, only pure Assembler Code) sees (_BlaBla) loads the _BlaBla address to a temp memory place
Should the temp memory be after past 0x00FFFFFF this could end up with Bus error since the bus is 24 bit long (while the processor never had to know that)
I sense something totally incorrect was said now but I can't know what. Please help me some more
PS: By the way CPU Reference manual says nothing about direct or indirect access to memory places when refering to the move instruction
Melear Charles-rdph40 <charles.melear@...> wrote:Jeff,
I am just a hardware guy. I know in the past that this ".w" vs ".l" addressing has cropped up and that it was solved by specifically adding the ".l", i.e., (A0).l.
I've got to tell you, I am not a software guy and I can't write more than just a few lines of C. (void main void is my knowledege of C) So, I am not really able to address such issues as "what compiler would be crazy enough". I caught on to this several years ago when I reverse assembled some code. That is, I took the machine language and translated that back into assembly instructions and then (with help from others) found the C instruction that created the assembly language instruction. Then the original programmer did some majic that forced the compiler to always use long word addressing which solved his/her original problem that was similar to the one being addressed in this email thread.
This, unfortunately, is my sum total of knowledge on the subject. I think I am going to learn how to write C just as soon as I get time.
Regards,
Charlie
-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Tuesday, March 04, 2003 11:07 AM
To: 68300@yahoogroups.com
Subject: RE: [68300] Re: Theoretical questions
Charlie,
I am shocked that any assembler would default to word addressing for the
instruction example you give,
MOVE.B #$12, (A0)
especially if you're saying that they originally did it for performance and
for the 68000. First of all, the 68000 can't even perform that instruction
with word addressing (A0.W). Second, on the CPU32, word addressing is
slower (and bigger) than longword addressing for that instruction because
it uses a suppressed address register to get word addressing.
What compiler or assembler is that crazy??
Jeff
Melear Charles-rdph40 <charles.melear@...> on 03/04/2003 09:42:04
AM
Please respond to 68300@yahoogroups.com
To: "'68300@yahoogroups.com'" <68300@yahoogroups.com>
cc:
Subject: RE: [68300] Re: Theoretical questions
Dimiter,
You are right about self-respecting compilers. However, there are several
legal modes of operation that can be specified here.
Consider this instruction -- move.b #$12,(A0)
A0 contains $12345678.
As written, this instruction will store the immediate value to the external
physical address $5678 *IF* the compiler defaults to "word" addressing.
Many compilers do default to WORD (as opposed to Long Word) addressing.
If the instruction is written like this: move.b #$12(A0).l (the ".l"
forces long word addressing)
Then, for sure, the immediate value of $12 will be written to the external
physical address $12345678.
Note that the ".b" after the instruction means that only "8-bits" of data
is being used. You are very correct, once again, that no one should try to
put 16-bits or 32-bits in the immediate data field of the instruction.
However, the problem is not with the data size, it is with the size of the
address in the (A0) field. Without explicitly specifying whether the first
16-bits or the full 32-bits of the address is used, the compiler might pick
the size that the programmer is NOT expecting.
If a 16-bit, sign extended address was used in our present example, the
effective address would be $00005678. If, however, A0 contained $1234D678,
then the 16-bit sign extended value would be $FFFFD678.
So, this is the issue that I am talking about, i.e., make sure that the
compiler picks the right addressing mode.
For people who write in C (or other high level language) it is important to
know about these hardware issues and I know this type of stuff happens. It
might not be the answer to the immediate problem but it is a possibility.
The BERR could be caused because the program is writing to an address that
the programmer did not mean to access.
If you want to really get into compiler generated hardware issues, we can
cover some stuff regarding Timer Processor Unit interaction with
read-modifiy-write instructions and registers with self-modifying bits.
But that is a discussion for another time.
regards,
Charlie
-----Original Message-----
From: Dimiter Popoff [mailto:dimiter.popoff@...]
Sent: Tuesday, March 04, 2003 9:28 AM
To: 68300@yahoogroups.com
Subject: [68300] Re: Theoretical questions
Any self-respecting compiler or assembler should issue an error
message if one tries to fit into a word an address bigger than
that (notice that the 68K family treats .w absolute addresses as signed
integers, i.e. the physical address is the sign-extended value
of the .w).
This sounds to me more like an attempt to access non-exsitant
memory - which gets caught by the bus monitor after hanging for
a while and is BERR-ed.
At any rate, BERR has little or nothing to do with 24 vs. 32
address bits as long as you attempt to access existing hardware
resources in your system.
Dimiter
--------------------------------------------------------------------
Dimiter Popoff
http://transgalactic.freeyellow.com <http://transgalactic.freeyellow.com> < http://transgalactic.freeyellow.com <http://transgalactic.freeyellow.com> > < http://transgalactic.freeyellow.com <http://transgalactic.freeyellow.com> < http://transgalactic.freeyellow.com <http://transgalactic.freeyellow.com> > >
-----Original Message-----
From: iomer@...
Sent: Tuesday, March 04, 2003 4:39 AM
To: 68300@yahoogroups.com
Subject: [68300] Theoretical questions
Could somebody explain to me why a Bus error exception shall occur
when commands like
MOVE.L (_BlaBla),A1 or
ADD.L A2,(_Blabla)
Well it seems the problem is the indirect access to the var. In
cpu32rm there is no word about indirect access from memory site
I suspect the problem is caused by the address bus being 24 bit long
while the address registers are 32 bit
Yet I could use a better explanation
Yahoo! Groups Sponsor
ADVERTISEMENT
<
http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl <http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl> < http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl <http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl> >
>
<
http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S <http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S> < http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S <http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S> >
=:HM/A=1464858/rand=452480932
>
---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com
To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> < http://www.motorola.com/mcu <http://www.motorola.com/mcu> > < http://www.motorola.com/mcu <http://www.motorola.com/mcu> < http://www.motorola.com/mcu <http://www.motorola.com/mcu> > >
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <
http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> < http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > > .
[Non-text portions of this message have been removed]
---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com
To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> < http://www.motorola.com/mcu <http://www.motorola.com/mcu> >
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> < http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> >
Yahoo! Groups Sponsor
ADVERTISEMENT
< http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl <http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl> >
< http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S=:HM/A=1464858/rand=133611028 <http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S=:HM/A=1464858/rand=133611028> >
---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com
To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> < http://www.motorola.com/mcu <http://www.motorola.com/mcu> >
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service < http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > .
[Non-text portions of this message have been removed]
Yahoo! Groups SponsorADVERTISEMENT
---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com
To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
---------------------------------
With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
[Non-text portions of this message have been removed]
Yahoo! Groups Sponsor
ADVERTISEMENT
<http://rd.yahoo.com/M=246920.2960106.4328965.2848452/D=egroupweb/S=1706554205:HM/A=1464858/R=0/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_Cquo_1/g22lp?Target=mm/g22lp.tmpl>
<http://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S=:HM/A=1464858/rand=383682384>
---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com
To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]Message
RE: [68300] Re: Theoretical questions
2003-03-05 by Melear Charles-rdph40