[Oberon] Wojtek's comment

Jan de Kruyf jan.de.kruyf at gmail.com
Tue Sep 1 19:26:10 CEST 2015


Peter,

> If you change the stack pointer in that procedure, of course you either
> have to check from where you are being called or you must not use that
> procedure from within the wrong stack.

Ja thats clear, I was checking if there was more on your mind, Thanks.

j.


On Tue, Sep 1, 2015 at 5:38 PM, Peter Matthias <PeterMatthias at web.de> wrote:

>
>
> Am 29.08.2015 um 21:52 schrieb Jan de Kruyf:
> > Peter,
> >
> >  > If someone wants a stack in fast ram,
> >  > allocate same data and let the exported procedures do the change of
> the
> >  > stack pointer. Don't use exported procedures local.
> >
> > Do you mean to say: "Don't use exported procedures locally *because*
> > they will
> > confuse the stack pointer"? (since you advise to let the exported
> > procedures do
> > the change of the stack pointer.)
> > Do I understand that right?
>
> If you change the stack pointer in that procedure, of course you either
> have to check from where you are being called or you must not use that
> procedure from within the wrong stack.
>
> Peter
>
> >
> >
> > On Sat, Aug 29, 2015 at 9:22 PM, Peter Matthias <PeterMatthias at web.de
> > <mailto:PeterMatthias at web.de>> wrote:
> >
> >
> >
> >     Am 29.08.2015 um 13:40 schrieb John R. Strohm:
> >     > ---PeterMatthias at web.de <mailto:PeterMatthias at web.de> wrote:
> >     >> Until a generalized solution is found I would simply scan for the
> module
> >     >> names in linker that need code and/or data in fast ram and
> allocate it
> >     >> there. A generalized solution would be to mark code/date in a
> special
> >     >> way and let the linker do the allocation automatically.
> >     ...
> >     > I'd suggest (based on DSP experience) that, if you allow
> procedures to be marked for fast RAM, you restrict such marking to leaf
> procedures.
> >     >
> >     > The alternative is to do a transitive closure on the marked
> procedure: Any procedure called by a procedure marked to be located in fast
> RAM must also be located in fast RAM.  This is a good way to use up fast
> RAM very quickly, if you make one bad call decision.
> >
> >     Both true. However, marking code on procedure level would be
> difficult
> >     to implement. On module level it's easy to implement and can be
> >     restricted to leaf modules. If someone wants a stack in fast ram,
> >     allocate same data and let the exported procedures do the change of
> the
> >     stack pointer. Don't use exported procedures local.
> >
> >     > I also agree with the guy who said you want all of the fast RAM
> allocation information in ONE place, to make it easier to manage it all,
> which argues against marking individual procedures, and argues in favor of
> a linker control file.  I've had to do this, on a fair-sized embedded DSP
> project.  It was a headache and it remained an ongoing headache.
> >
> >     Also true. If you can't get your code into one fast ram module it
> gets
> >     complicated. If it fits, it should be easy.
> >
> >     Peter
> >
> >     --
> >     Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch> mailing
> >     list for ETH Oberon and related systems
> >     https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
> >
> >
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
> >
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150901/9a2ed497/attachment.html 


More information about the Oberon mailing list