[Oberon] Wojtek's comment

[Jan de Kruyf]

hi Peter,

> English is not my native language.

Heraus mit der Sprache Mensch! :)

> published openly.

Somewere in the dark recesses of my mind I remembered that Native2.3.6 is
fully documented, yes.

> simply scan for the module names in linker that need code and/or data in
fast ram and allocate it there.

Yes, make it part of the boot code then perhaps.
But that could also be done in the dynamic linker.

But there is also the bit about the stack that Jörg remembered.

Vielleicht noch ein Bisschen am Denkplatz sitzen. :)

cheers,
j.


On Sat, Aug 29, 2015 at 12:24 PM, Peter Matthias <PeterMatthias at web.de>
wrote:

> Hi Jan,
>
>
> Am 28.08.2015 um 16:47 schrieb Jan de Kruyf:
> > Hallo Peter,
> >
> > Don't know whether you followed the thread about Wojtek's needs in FPGA
> > programming.
>
> I read the thread, but only fast and English is not my native language.
>
> > I am very aware of Native Oberon's way of doing things. If you look long
> > and hard you will still find my name in some beta-testers list from the
> > time that Peter Muller ran Native + Gadgets.
>
> Me too :-)
>
> >  > a static one for the inner core
> >
> > This seems one of the trade secrets of ETH :) never found any code yet.
> > I am aware it exists.
>
> The core system code was secret in last millennium. Since beginning of
> current millennium all code at least for the original system is
> published openly.
>
> > Perhaps calling it the linker script leads people astray.
> > In an earlier post I wrote this:
> > -- So this morning I had a quick look in chapter 14 of the new 'Project
> > Oberon' and in the source files
> > -- that control the boot process. At the moment most addresses are hard
> > wired and difficult to decipher for a novice.
> > -- So I think what might be done is: make a 'boot parameter' module,
> > that exports just the required variables
> > --  with copious explanation --,  that is imported into the regular
> > bootloader, Kernel etc.
> > This was in response to the need to execute code from high speed Bram
> > and the need to memory map hardware on his FPGA.
>
> As I understood, there are two topics:
> a) accessing hardware in a type safety way
> b) utilizing fast hardware (BRAM) of the system
>
> While I see no sense in a), b) is a necessity.
>
> 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.
>
> Regards,
>         Peter
>
>
>
> --
> 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/05de31da/attachment.html