[Oberon] Wojtek's comment

[Jan de Kruyf]

John, good day.

> 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.

We have not seen yet the exact scope of work that needs to be done fast.
This is a data gathering , with perhaps some DSP, application. So lets wait
and see first.
Your suggestion is valuable though, if this is at all possible.

A question:
how did you handle the stack between slow and fast execution parts of the
program? Or did it run in separate threads, making the stack business
automatic?
You see, I know zippo about embedded DSP. Have you got a link to some data
sheet / application notes perhaps?

cheers,

j.



On Sat, Aug 29, 2015 at 1:40 PM, John R. Strohm <strohm at airmail.net> wrote:

> --- 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.
>
> In one of the later versions of the Oberon compiler, Prof. Wirth added a
> special mark to denote leaf procedures.  This kinda bugged me, as the
> compiler can easily determine whether a procedure is a leaf procedure or
> not, but it makes sense if you are writing a quick-and-dirty one-pass
> generate-IMMEDIATELY compiler, as opposed to building an abstract syntax
> tree and waiting until you have the entire procedure in front of you and
> can generate the code for it all at once.
>
> 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.
>
> 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.
>
> --John R. Strohm
>
> --
> 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/20150829/5cadd852/attachment.html