Re: C to Java Byte Code

From: Thomas Stegen (tstegen_at_cis.strath.ac.uk)
Date: 10/26/04 

Date: Mon, 25 Oct 2004 23:34:02 +0100

Paul Lutus wrote:

> <cl7gbh$7th$1@hood.uits.indiana.edu>
>
> *******************************************************************
>
> "The size of each char, int, long, or float is 1 word (32 bits long).
> So, sizeof(int) is 1, sizeof(char) is 1, sizeof(float) is also 1,
> you got the idea. Using a large array of int to mimic addressable memory is
> the cause for this. The indexes to this large array are treated as
> addresses. This memory is word-addressable and not byte-addressable.
> And programs that assume a byte-addressable architecture will need to be
> modified to suit the one used by MPC. Unions are supported."
>
> *******************************************************************
>
> If, as the OP claims, all data are 32-bit words, then the claim that unions
> are supported is false, since (1) Java will not allow disparate data types
> to be overlaid in memory, and

Quite clearly the results from running code posted in this thread
shows that MPC handles this correctly.

> (2) a union's purpose is the mapping of
> disparate data types, and there aren't any disparate data types.

Can you please provide a reference from the standard for this claim.
I find no such wording anywhere.

As a starting point I suggest (of C99) 6.2.5, 6.5.2.3, 6.7.2.1.
Though I couldn't find anything there myself, you will probably
have to look elsewhere.

>
> BTW there is also no support for anything that requires fewer or more than
> 32 bits, e.g no support for typical doubles as just one example.

This specific compiler is not 100% ISO C compliant, I agree. But its
support of unions is compliant to ISO C. I see mp reason that the other
issues I know of with this compiler cannot be solved.

I am curious, you seem to say this is impossible in the general case.
So, can you please give an example of a C program that cannot be validly
compiled to Java byte code according to the ISO C standard. If you are
using some other benchmark for what a C compiler is than the ISO C
standard please provide some definition for what you mean (and I can
also win any argument using definitions that suit me).

According to the standard a compiler is a C compiler if it can compile
any strictly conforming program. A program that assumes byte addressable
memory is not a strictly conforming C program.

If your claim is only about this specific instance then you are right in
saying that it is not an ISO C compiler (strictly speaking), but your
union argument does not provide evidence for this as the resulting code
is valid according to the standard. 

-- 
Thomas.

Relevant Pages

  • Re: made it to page 4 of gforth tutorial
    ... support recursion other than tail recursion, ... follow the C standard. ... have trouble calling that a C compiler. ... fully support recursion. ...
    (comp.lang.forth)
  • Re: Why VLAs are useful
    ... This compiler supports complex but not VLAs, ... How does that differ from the current situation, with incomplete support ... That standard was a success. ... The common wisdom is that the C99 ...
    (comp.std.c)
  • Re: COBOL COMPILER BLUES...
    ... I'm pretty sure Walter is still on the list, ... engineer providing lab support for the compiler, ... product and required little support. ... The standard does not address such things as how the compiler ...
    (comp.sys.hp.mpe)
  • Re: help me learn C
    ... I have been on here over 14 years but a member of the ISO C panel for ... If you want to discuss ISO C there is Comp.std.c ... OS or a compiler etc there are specific groups for that. ... that is only used in the standard, but virtually no where else, to ...
    (comp.lang.c)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... It would be amazingly stupid of a compiler vendor to not support a byte-sized integer. ...
    (comp.lang.fortran)