[am56@dial.pipex.com: Re: Support of separate address spaces]

[acken@informatik.uni-kl.de]

Date: Thu, 22 Feb 1996 00:47:47 +0000
From: Stefan Heinzmann <am56@dial.pipex.com>

mva wrote:

>>...
> I can't find much questions in your posting ;-).  It's interesting
> nevertheless.  I don't know anything about DSP architectures.  I'm
> wondering how those 2 data spaces are managed:
> Are the physically seperated, ie do they correspond to seperate memory
> banks?  How are they accessed: by different opcodes or by some
> indexing scheme?  By which criteria does the programmer decide which
> space to use for a particular chunk of data?

The two data spaces are physically separate (X and Y), at least on-chip,
to allow simultaneous accesses to both. Off-chip, both buses are merged
to save pins and the data spaces are distinguished by a control signal.
If the chip accesses both data spaces at the same time with addresses
that are not implemented on-chip, the accesses get serialized, thereby
slowing down the chip.

If you take instruction fetch into account, the CPU can fetch 3 words of
data simultaneously: one each from program space and both data spaces.
Optimum speed results if at most one of these accesses go to off-chip
memory. The goal is to make the calculation of a sum of products as fast
as possible, because signal processing algorithms rely heavily on this.
Therefore, the DSP can fetch two factors from memory, multiply them and
add up the result in an accumulator in a single machine cycle.

It is encoded in the instruction which data space is used for a
particular access. In general, X and Y are interchangeable, but if two
simultaneous accesses are to be made, one has to be in X space and one
in Y space.

I believe it is a very hard task to automatically optimize variable
placement in order to achieve maximum throughput with an architecture
like this. I doubt that a high level language is useful for the most
speed critical parts of a DSP program. I expect that assembler will be
used here in practise. This is not a problem since it applies to fairly
small amounts of code. The purpose of a high level language lies in the
general purpose code which is far less critical. It is not exceptional
that a DSP will be used for both signal processing and general control
tasks, spending 95% of processor time in a highly optimized small
subroutine doing the filtering and 5% of the time in a large control
program that is not very time critical. The latter is where I see a role
for a high level language.

C compilers have been available for a while to support this, but code
quality is usually quite appalling, both in speed and size. I don't
understand fully why this is the case. Probably there is little effort
spent for optimization.

As a side issue, the unit of addressing on the DSP is a 24-bit word
rather than a byte. I wonder how many programs are in some hidden way
dependant on the unit of addressing being a byte as in most computers.
The Oberon Report - as far as I know - doesn't imply anywhere that it
has to be a byte.

>>...
> To add the address space as an attribute to Oberon-2 types seems to be
> a bit coarse in granularity.  This would imply to put all variables
> resp. heap objects of a particular array type into a single address
> space, which may reduce the efficiency of some algorithms working on
> them (since only a single data space is used).

Admitted. But wouldn't it change the syntax of the language quite a lot
to mark every variable with a data space identifier? Or should this be
done outside of the source code by some kind of "linker guide file"
(which doesn't work for heap variables - a parameter for NEW would be
needed here).

>>...

>[ stuff deleted ]

> You could add an additional flag to parameter declarations that
> specifies which address space has to be used for the actual parameter
> being passed to it.  If the procedure is called with a parameter that
> is located into the wrong space, you can create a copy of it and pass
> a reference to this copy to the callee.  For variable parameters the
> copy has to be transfered back to the old location afterwards.  Note
> that this modifies the semantics of the VAR parameter in certain
> situations, changing it from `pass per reference' to `copy in/copy
> out'.  Some (but not much) procedures may depend on the `per
> reference' semantics.

Hm, doesn't sound too bad, but I'd like a warning in this case, because
it can introduce considerable overhead.

>>...
> There is no support planned.  But we are flexible.  I don't think it
> will need much changes (if any at all) to the front-end to support
> your 2 data spaces.  OOC's intermediate represenatation should be able
> to handle this without any changes.  IMO this is a `back-end issue'.

Well, if you have those flags for address space marking, the frontend
will have to deal with them and the intermediate representation needs to
incorporate this information, so I can imagine that the whole thing is
less trivial than it may seem.

Is it worth defining a syntax for this kind of address space tagging
which is sufficiently general to be used with various different
processor architectures yet does depart from current oberon as little as
possible? Something like "Oakwood Guidelines for Address Space Tagging"?
It would at least mean that the frontend can be enabled for it and it is
up to the backend developers to decide whether to support it or not. I
can hear the guardians of the holy grail of purity scream out already!

> -- Michael van Acken

Stefan