[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