[Oberon] Wojtek's comment

[Jörg Straube]

John
In ProjectOberon, RISC5  is the Assembly language and the compiler is your friend :-)
Jörg

> Am 29.08.2015 um 21:54 schrieb John R. Strohm <strohm at airmail.net>:
> 
> As I recall, I went to a great deal of trouble to write the code so it didn't touch the stack during the fast routine.  You can live with stack hits before you pipe up the OUTER loop, and after it has completed.  You can't live with stack hits in the middle of the loop(s).
> 
> Assembly language is your FRIEND sometimes.  (If you can track down, say, a good radix-2 or radix-4 FFT for a real DSP, it will give you some insight.  Start by reading an FIR filter, though.)
> 
> Hit the TI website and pull down some of their app notes.
> 
> --- jan.de.kruyf at gmail.com wrote:
> 
> From: Jan de Kruyf <jan.de.kruyf at gmail.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] Wojtek's comment
> Date: Sat, 29 Aug 2015 13:54:03 +0200
> 
> 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
> 
> -- 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/20150830/c8d68656/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2376 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20150830/c8d68656/attachment-0001.bin