Re: Generating Java Bytecode

Joe Hummel writes:


> [..] Ada doesn't support general pointers, at least it doesn't support
> things like
>
> int i, *p;
>
> p = &i;
> p++;


      Ada 95 supports these constructs (see the aliased keyword, and the
System.Storage_Elements package).


> I would imagine that Ada does support something like:
>
> p = (void *) 0x0080001F;
>
> so I don't know how they get around this. Perhaps they don't support
> it? Anyone know? [...]


      My guess is that the Ada->Java compiler takes advantage of
RM95-1.1.3(6):


| 1.1.3 Conformity of an Implementation with the Standard
| [...]
| 6 Contain no variations except those explicitly permitted by this
| International Standard, or those that are impossible or
| impractical to avoid given the implementation's execution
| environment;
|
| 6.a Implementation defined: Variations from the standard that are
| impractical to avoid given the implementation's execution
| environment.
|
| 6.b Reason: The ``impossible or impractical'' wording comes from
| AI-325. It takes some judgement and common sense to interpret
| this. Restricting compilation units to less than 4 lines is
| probably unreasonable, whereas restricting them to less than 4
| billion lines is probably reasonable (at least given today's
| technology). We do not know exactly where to draw the line, so
| we have to make the rule vague.


      The JVM explicitly rules out pointer arithmetic, so it's a
perfectly reasonable restriction (not to support address arithmetic,
and integer/address convertion) for a JVM targeted compiler.


      You can also support integer addresses by faking the memory by a
big array of bytes (after all...), but it's not very useful. On a Java
chip with memory instructions, I assume an Ada implementation will be
able to implement a real version ;-).


--
Laurent Guerby <guerby@gnat.com>, Team Ada.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.