[Oberon] Oberon FPGA hardware point of view
Chris Burrows
chris at cfbsoftware.com
Sat Aug 11 07:34:24 CEST 2018
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Andreas Pirklbauer
> Sent: Friday, 10 August 2018 11:21 PM
> To: ETH Oberon and related systems
> Subject: [Oberon] Oberon FPGA hardware point of view
>
> > No - that would not work well for me. It would mean I would
> > have to maintain up to 11 different copies of *every* source
> > code file that currently IMPORTs MCU - the only difference
> > being the IMPORT statements.
>
> I see. Good.
>
> PS: I have experimented with modifying the semantics of module
> contexts, where the loader *automatically* imports a module from the
> same contexts. In that case, I suppose, you could use it (it s in
> fact the current restriction in EO).
>
> But I think your folder-based system is better anyway, as it does not
> require you to modify the language.
>
Yes - but more than that we use the 'search path' system throughout Astrobe to locate files when:
* Opening a source code file in the editor from the IMPORT list
* Locating object files when linking an application
* Locating source, symbol and object files by the 'Build' tool
The Build tool is my favourite. Given a module, it automatically compiles the current (target) module, and any out-of-date modules that it imports (directly or indirectly). It inspects the source code of the modules to determine the import dependencies. It then compiles any modules that need recompiling in the correct sequence. This ensures that the resulting object code files for the modules are all compatible with each other.
For example, if you have the sources of the Project Oberon operating system but hadn't yet compiled anything, if you 'build' the following source code file:
MODULE BuildAll;
IMPORT
Edit,
Net,
ORP,
ORTool,
PCLink1,
System,
Tools;
END BuildAll.
The system automatically compiles the 7 modules that are imported and the 19 other modules that they depend on. There is no need to maintain any 'makefile' as the files can all be identified by traversing the IMPORT lists in the sources. On my Windows system this whole operation takes 800 ms to compile everything from source. Subsequently, it takes 300 ms to check that nothing needs to be compiled.
Regards,
Chris
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5
More information about the Oberon
mailing list