<div dir="ltr"><div>Peter,</div><div><br></div><div>> If you change the stack pointer in that procedure, of course you either</div><div>> have to check from where you are being called or you must not use that</div><div>> procedure from within the wrong stack.</div><div><br></div><div>Ja thats clear, I was checking if there was more on your mind, Thanks.</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 5:38 PM, Peter Matthias <span dir="ltr"><<a href="mailto:PeterMatthias@web.de" target="_blank">PeterMatthias@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
Am 29.08.2015 um 21:52 schrieb Jan de Kruyf:<br>
> Peter,<br>
><br>
> > If someone wants a stack in fast ram,<br>
> > allocate same data and let the exported procedures do the change of the<br>
> > stack pointer. Don't use exported procedures local.<br>
><br>
</span>> Do you mean to say: "Don't use exported procedures locally *because*<br>
<span class="">> they will<br>
> confuse the stack pointer"? (since you advise to let the exported<br>
> procedures do<br>
> the change of the stack pointer.)<br>
> Do I understand that right?<br>
<br>
</span>If you change the stack pointer in that procedure, of course you either<br>
have to check from where you are being called or you must not use that<br>
procedure from within the wrong stack.<br>
<br>
Peter<br>
<span class=""><br>
><br>
><br>
> On Sat, Aug 29, 2015 at 9:22 PM, Peter Matthias <<a href="mailto:PeterMatthias@web.de">PeterMatthias@web.de</a><br>
</span><span class="">> <mailto:<a href="mailto:PeterMatthias@web.de">PeterMatthias@web.de</a>>> wrote:<br>
><br>
><br>
><br>
> Am 29.08.2015 um 13:40 schrieb John R. Strohm:<br>
</span><span class="">> > ---<a href="mailto:PeterMatthias@web.de">PeterMatthias@web.de</a> <mailto:<a href="mailto:PeterMatthias@web.de">PeterMatthias@web.de</a>> wrote:<br>
> >> Until a generalized solution is found I would simply scan for the module<br>
> >> names in linker that need code and/or data in fast ram and allocate it<br>
> >> there. A generalized solution would be to mark code/date in a special<br>
> >> way and let the linker do the allocation automatically.<br>
> ...<br>
> > 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.<br>
> ><br>
> > 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.<br>
><br>
> Both true. However, marking code on procedure level would be difficult<br>
> to implement. On module level it's easy to implement and can be<br>
> restricted to leaf modules. If someone wants a stack in fast ram,<br>
> allocate same data and let the exported procedures do the change of the<br>
> stack pointer. Don't use exported procedures local.<br>
><br>
> > 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.<br>
><br>
> Also true. If you can't get your code into one fast ram module it gets<br>
> complicated. If it fits, it should be easy.<br>
><br>
> Peter<br>
><br>
> --<br>
</span>> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> <mailto:<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a>> mailing<br>
<div class="HOEnZb"><div class="h5">> list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
><br>
><br>
><br>
><br>
> --<br>
> <a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
><br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>