68300

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]