Re: [Simulavr-devel] anacomp getting reserved access messages

[Joel Sherrill]

Joerg Wunsch wrote:
> As Joel Sherrill wrote:
>
>   
> > 0x3d - 0x3e should allow writes but a read does not
> > have to return the value previously written?
> >     
>
> 0x3d is SPL, and is always implemented, accept on devices with a
> hardware stack which we can ignore as they are all obsolete now (like
> the venerable AT90S1200, but there have also been a couple of early
> ATtiny devices).  They cannot be handled by the compiler frontend
> either (only assembler and linker).
>
> 0x3e SPH, and is only implemented on devices that can address SRAM
> beyond 0xFF.  As the classic AVR core maps the CPU registers into SRAM
> addresses 0 through 0x1f, and IO registers to 0x20 through at least
> 0x5f, this only applies to AVRs with 128 (or less) bytes of SRAM.
>
>   
Thank you for the very detailed explanation.
> > Or is it acceptable to mirror back the value written.
> >     
>
> As SPH is a reserved register on those devices, anything is
> acceptable: return 0, or just behave as a real register, and mirror
> the value back.  Actually, the compiler-generated code will never have
> a reason to modify anything on its value on those devices, so it will
> always write back the value read before (probably 0).
>
>   
> > And this should be the behaviour on all current models
> > supported:
> >
> >  at90s4433
> >  at90s8515
> >  atmega48
> >  atmega128
> >     
>
> Out of those, only the AT90S4433 features SRAM addresses that cannot
> exceed 0xFF, so it doesn't implement SPH.  The other three AVRs do
> implement a real SPH register which is also to be taken into account
> when accessing the stack.
>   

I am convinced that simulavrxx is correct on this now. There
are even special RWSpl and RWSph classes. :)

The issue is that on the at90s4433 gcc is generating accesses
to both sph and spl. And sph doesn't technically exist but accesses
are allowed in a benign way on real hardware.

To silence the message and be more true to gcc's behavior on
real hardware, is this OK:

Index: at4433.cpp
===================================================================
RCS file: /sources/simulavr/simulavrxx/src/at4433.cpp,v
retrieving revision 1.10
diff -u -r1.10 at4433.cpp
--- at4433.cpp 26 Mar 2009 19:03:48 -0000 1.10
+++ at4433.cpp 26 Mar 2009 20:58:19 -0000
@@ -76,7 +76,7 @@
mcucr= new HWMcucr(this); //, irqSystem, PinAtPort(portd, 2), 
PinAtPort(portd, 3));

rw[0x5f]= new RWSreg(this, status);
- rw[0x5e]= new RWReserved(this, 0x5e);
+ rw[0x5e]= new RWSph(this, stack); // not really but benign
rw[0x5d]= new RWSpl(this, stack); //only 8 Bit Stack Pointer in 4433
rw[0x5c]= new RWReserved(this, 0x5c);
rw[0x5b]= new RWGimsk(this, extirq, portd);

>   
> > > (I
> > > know VMlab always complains about it, it can be a little annoying.)
> > >       
>
>   
> > I don't like warnings or hints of errors.
> >     
>
> Technically, it's GCC which is on error here, but the error has proven
> to be benign for 10 years now.
>
>   
:) It is easier to change this one line of code than gcc. :)


--
Joel Sherrill, Ph.D.             Director of Research & Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985