Support of separate address spaces

[Stefan Heinzmann <am56@dial.pipex.com>]

Hi there,

being new to this list, I beg your pardon if I'm asking silly questions.

I'm reasoning about the implications of writing a compiler for a DSP
architecture (esp. the Motorola 56k-Architecture). This DSP-family, like
many others, have one address space for code and two for data. This is a
hardware trick to speed up multiplications (two operands can be fetched
simultaneously). I'm thinking about efficient ways of supporting these
in a high-level language like Oberon.

A sufficiently general solution should also support segmented
architectures like the Intel 386. I know that a single flat address
space is often the simpler solution and greatly preferred by
C-programmers, but there are cases where distinct adrress spaces are
desirable.

Oberon, being a strongly typed language, should qualify well for such a
task, because the address space can be an attribute of a variable's type
and therefore be managed by the compiler. The goal is of course to
minimize the runtime overhead.

I gather it is quite straightforward to separate code from data space,
because it is always known whether a pointer or reference refers to code
or data in Oberon. If there are hidden problems here, alert me please.

A more tricky question is, whether the stack space, the global
variables, and the heap can be separated without introducing a lot of
runtime overhead. The most likely separation seems to be between a heap
space and a global/stack space. Explicit pointers point to heap space in
Oberon, so this isn't a problem. Runtime tags are not necessary here.

However calls by reference (VAR arguments) pass an implicit pointer to
the called procedure. This implicit pointer can point to stack or global
or heap variables. Since the called procedure has to know which address
space the reference is referring to, an address space tag has to be
passed together with the implicit pointer. This may introduce
considerable runtime overhead.

To avoid tagging the pointers like that, I can only imagine an
implementation restriction to the extent that these implicit pointers
always refer to stack/global space and if an access to heap space is to
be made, an explicit pointer has to be used. This will certainly break
existing code, although I have not yet studied how severe the
restriction would be in practice. What are your opinions; do you have
other solutions?

If more than one heap space needs to be supported, I could imagine this
can be solved by special base types that are empty but define the
address space for all their extensions.

Has anybody thought about this yet? Is ooc capable of supporting this or
is support for this planned? Is it something the frontend needs to know
or is it merely a backend issue? Pointers to literature? Flames?

Regards

Stefan