IDL interfaces

[Jonathan S. Shapiro]

> I'm confused about the comment at the end related to registers, spill,
etc.
> The e-speak IDL compiler takes e-speak IDL (a strict subset of Java) in
and
> spits out Java.  Isn't it always possible to spit out a high level
language?

In EROS/KeyKOS, the ultimate output of the IDL compiler is an operating
system trap instruction. Since there is a convention on each hardware
platform concerning placement of certain arguments in certain registers, a
good IDL compiler must ultimately emit a certain amount of assembler code.

The current strategy in EROS is to use high-level language to go to a
conventional structure and have a single set of universal assembly stubs
that do the final motion into and out of registers.

I now have permission to put the IBM paper on the EROS website, but it's
difficult to do that over a modem. The summary is that stub performance
matters in an EROS-like system.

> Why are thinnings a problem?  In e-speak Beta 3.0, the IDL compiler
> generates code for all the methods in the interface.  However, the
> capability you hold may only give you access to a subset of these methods.
> Isn't splitting the job this way simpler?

Yes it is simpler. There is no conceptual difficulty with this. It's just
that previous IDL compilers have tended to assume that methods in distinct
interfaces could be assigned "opcodes" (integer method names) independently,
and this isn't consistent with the assignment conventions currently used in
EROS. Perhaps, come to think of it, a simpler solution would be to give up
the universal numbering, but it's sure been convenient in writing the
implementations.


shap