Yahoo Groups archive

68300

Index last updated: 2026-04-29 00:01 UTC

Thread

Theoretical questions

Theoretical questions

2003-03-04 by johnmerm <iomer@egnatia.ee.auth.gr>

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

RE: [68300] Theoretical questions

2003-03-04 by Melear Charles-rdph40

Hello everyone,
 
When I receive questions like this, I try to offer simple answers that seem to trick a lot of people.  
 
Many compilers default to "word" length addressing unless specifically directed to do otherwise.  This is not the most general case, "long word" addressing is the most general case.  However, long word addressing uses more memory cycles than word addressing which uses more memory cycles than byte addressing.
 
So, your instruction "move.l (blabla),A1 probably treats (blabla) as a word address when you meant for it to be a long word address.
 
So, if this is the case, write the instruction this way:  move.l (blabla).l,A1  and add.l A2,(blabla).l
 
The ".l" will force the compilier to use long word addressing which will probably cure your problem.
 
 
 
Now, for you historical buffs, why would a compiler default to a case that is not the most general case?  The answer is that in the really, really old days the MC68000 ran at a blazing 4 MHz.  Yes, that's right, all you youngsters, 4 entire MHz.  It turned out that if code written for the MC68000 was compiled with a compiler that used long word addressing as the default, the code would take a significant performance hit.  So, someone got the bright idea of making "word" addressing as the default which speeded up external memory accesses considerably.  If the MC68000 was running a small program (less than 64 Kbytes) and the compiler defaulted to long word addressing, it turned out that many 8-bit processors (yes, only 8-bits) could present a significant challenge to the MC68000 performance.
 
That is why some compilers do not use long word addressing unless specifically told to do so.  Use the ".l" to force long word addressing and I'll bet that your Buss Errors go away.
 
Regards,
 
Charlie
Show quoted textHide quoted text
-----Original Message-----
From: iomer@... [mailto: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://us.adserver.yahoo.com/l?M=246920.2960106.4328965.2848452/D=egroupmail/S=:HM/A=1464858/rand=749477595> 	

---------------------------------------------------
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]

Re: Theoretical questions

2003-03-04 by Dimiter Popoff

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
Show quoted textHide quoted text
-----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

RE: [68300] Re: Theoretical questions

2003-03-04 by Melear Charles-rdph40

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
Show quoted textHide quoted text
-----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> 




-----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://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> 



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]

RE: [68300] Re: Theoretical questions

2003-03-04 by jeffrey.tenney@gm.com

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:
Show quoted textHide quoted text
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>




-----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://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>



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]



---------------------------------------------------
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



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

RE: [68300] Re: Theoretical questions

2003-03-04 by Melear Charles-rdph40

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
Show quoted textHide quoted text
-----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> >




-----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://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> >



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]



---------------------------------------------------
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 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://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> 



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]

RE: [68300] Re: Theoretical questions

2003-03-05 by John Mermigis

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
Show quoted textHide quoted text
-----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> >




-----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://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> >



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]



---------------------------------------------------
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 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://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> 



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]


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



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]

RE: [68300] Re: Theoretical questions

2003-03-05 by Melear Charles-rdph40

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
Show quoted textHide quoted text
 -----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]

RE: [68300] Re: Theoretical questions

2003-03-05 by Melear Charles-rdph40

John,
 
Bye the bye, LEA only has a 32-bit form, i.e., it always uses Long Word addressing.
 
Also, move.l also forces Long word addressing because a 32-bit quantity is being moved internally between 32-bit source and destination.
 
So, the problem of inadvertantly moving a 16-bit value instead of an intended 32-bit value is solved.
 
regards,
 
Charlie
Show quoted textHide quoted text
-----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]

RE: [68300] Re: Theoretical questions

2003-03-05 by jeffrey.tenney@gm.com

John,

You can review the addressing modes (direct, indirect, absolute, etc.) of
the CPU32 in the CPU32RM, chapter 3.  However, the CPU32 does not do
"memory indirect" addressing,  meaning that an address stored in data
memory is useless until *you* load it into a register.  (The assembler
wouldn't do that for you.)

The instruction:

move.l $12345678, A1

uses absolute-long addressing.  The address $12345678 is stored as part of
the machine language of the instruction (in code memory).  The CPU32 gets
the address during the instruction fetch.  When the CPU32 is executing the
instruction, it puts $12345678 out on the address bus in a "read" cycle.
However, because the address bus is only 24 bits wide, the leading byte $12
never appears anywhere on the bus.  So all of the chip-select logic (even
the external stuff if you have any) sees only 24 bits and responds
accordingly.  Effectively, what that means is that $12345678 refers to the
same address as $FF345678.  Neither causes a bus error as long as $345678
and $34567A are valid addresses and word readable.

As an interesting side note, the upper byte of a 32-bit address can
actually have an effect on performance.  Consider the instruction:

move.w $00FFFA44, D0

which moves CSPAR0 to D0.  It is assembled with absolute-long addressing
since $00FFFA44 does not fit into a word.

However,

move.w $FFFFFA44, d0

also moves CSPAR0 to D0.  This instruction is assembled with absolute-short
addressing because $FFFFFA44 *does* fit into a word, namely $FA44.  This
instruction is smaller and faster than the absolute-long equivalent.

Jeff





John Mermigis <johnmerm@...> on 03/05/2003 04:03:07 AM

Please respond to 68300@yahoogroups.com

To:    68300@yahoogroups.com
cc:
Show quoted textHide quoted text
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

<snip, snip>

TPU emulation on 68LK332

2003-03-07 by Allen Nance

Hello group:

	Has anyone used the TPU emulation RAM as TPU code space
on the 68LK332 (3V part)? Should it work? I have an application which
runs on a 5V part that is crashing on the 3V part. If I take out the
TPU emulation RAM init, it works fine (of course without the TPU functions).

Any ideas out there?

Allen

Re: [68300] TPU emulation on 68LK332

2003-03-07 by Allen Nance

Hello Again:

         I found the problem. Yes, the TPU emulation does work on the 68LK332.
I had a bug in my old code that for some strange reason didn't show up on the
5V part. When I have time maybe I can find out why.

It's nice to send my questions to someone, even in the middle of the night!!!

Thanks,
Allen



At 12:34 AM 3/7/2003 -0600, you wrote:
Show quoted textHide quoted text
>   Hello group:
>
>         Has anyone used the TPU emulation RAM as TPU code space
>on the 68LK332 (3V part)? Should it work? I have an application which
>runs on a 5V part that is crashing on the 3V part. If I take out the
>TPU emulation RAM init, it works fine (of course without the TPU functions).
>
>Any ideas out there?
>
>Allen
>
>
>
>
>
>
>
>---------------------------------------------------
>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
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

RE: [68300] Re: Theoretical questions

2003-03-07 by Iain A B Lindsay

Perhaps there is confusion between word/longword adressing (which has very
little to do with the address bus, apart from alignment restrictions) and
the absolute short and absolute long addressing modes.  The following
example, illustrating some of the variations possible when copying a 32-bit
datum and a 16-bit datum, from address $00000017 to address $0000002A, may
help:

    opcode       operands

32-bit copy

     21F8    0017 002A                  move.l	23.w, 42.w
     21F9    0000 0017 002A             move.l	23.l, 42.w
     23F9    0000 0017 0000 002A        move.l	23.l, 42.l
     23F8    0017 0000 002A             move.l	23.w, 42.l

16-bit copy

     31F8    0017 002A                  move.w	23.w, 42.w
     31F9    0000 0017 002A             move.w	23.l, 42.w
     33F9    0000 0017 0000 002A        move.w	23.l, 42.l
     33F8    0017 0000 002A             move.w	23.w, 42.l

-Iain..

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.