On 1/2/23 11:28 AM, Tristan B. Velloza Kildaire wrote:

> I am currently working on my own compiler for something like C

Define "like C".

DoDi
[Grouped with {} ? Comments with /* */ ? Designed by a guy who
worked for the phone company? -John]

On 2023/01/05 02:12, Hans-Peter Diettrich wrote:
> On 1/2/23 11:28 AM, Tristan B. Velloza Kildaire wrote:
>
>> I am currently working on my own compiler for something like C
>
> Define "like C".
>
> DoDi
> [Grouped with {} ?  Comments with /* */ ?  Designed by a guy who
> worked for the phone company? -John]

Think of C, but with object orientation similiar to C++ added, however
single inheritance, interface support (as per C++ as well). Really java
OOP's model but attached into C.

Kind of not too keen on generics as I think they blur source code
clarity somewhat. Still open to suggestions.

But stripped down C++ in the sense of avoiding many pitfalls such as
weird syntax for certain declarations.

There are other things I aim to fix, fixing the evaluation ordering of
function arguments (as that is unspecified) - this is done in the DGen
(C code emitter level). That's what I am going for.

I have a memory model for OOP planned out, the OOP features will come in at
a later stage, parsing and most of dependency tree initialization is
there but needs some tweaking. Currently working on getting modules
supported correctly.

Flow control is there from lex to emit, functions etc etc. Expressions
and all, I will keep everyone up to date and know when there is an alpha
out. I just want to polish the remaining needed features, the soirce
code itself (as I intend it to be readbale for others who want to
contribute).

Development has picked up quite a lot seeing that I now finished
university. STtarting work soon but intend to use free time to work on it.

When it is all polished I will open source it, clean up docs and also
work on the "book" section which aims to be a language manual and
implementation manual (explaining the inner workings).

On Friday, January 13, 2023 at 10:00:11 AM UTC-8, Tristan B. Velloza Kildaire wrote:

(snip)

> Think of C, but with object orientation similiar to C++ added, however
> single inheritance, interface support (as per C++ as well). Really java
> OOP's model but attached into C.

I always thought that Java was, intentionally, more like C than C++ is like C.

That was even before they added System.out.format(), which should make
C programmers even happier.

Some time ago, I was trying to figure out if you could make a C compiler
that generated JVM code. I would run much closer to the C standard
than much C code does, especially regarding casting of pointers.
[So what did you conclude? I'd think C type casts would be hard to
turn into Java unless you made all of storage an opaque block. -John]

On Friday, January 13, 2023 at 11:10:37 AM UTC-8, gah4 wrote:

(snip)

> Some time ago, I was trying to figure out if you could make a C compiler
> that generated JVM code. I would run much closer to the C standard
> than much C code does, especially regarding casting of pointers.

> [So what did you conclude? I'd think C type casts would be hard to
> turn into Java unless you made all of storage an opaque block. -John]

Someone else might have thought about the "opaque block" method.
But that wouldn't work if you wanted to call between Java and C.

As well as I know it, C only requires assignment to work for
pointers cast to (unsigned char *). And once they are cast,
usually (though I suppose not always), it is done with memcpy(),
or compared with memcmp().

So, all the complication of figuring out what is actually being
done, can be done inside one of those.

C pointers, then, are an object with a reference to the actual
array, and current offset within the array, and bounds for
the array. Pointer arithmetic only changes the offset.

Scalar variables that can be pointed to, compile as arrays
dimensioned [1].

I didn't get as far as figuring out varargs functions, but someone
must have done that, as System.out.format() works.
You can call it with the usual different argument types,
and it figures out everything.

On Fri, 13 Jan 2023 12:39:41 -0800 (PST), gah4 <gah4@u.washington.edu>
wrote:

> On Friday, January 13, 2023 at 11:10:37 AM UTC-8, gah4 wrote:
>
> (snip)
>
> > Some time ago, I was trying to figure out if you could make a C compiler
> > that generated JVM code. I would run much closer to the C standard
> > than much C code does, especially regarding casting of pointers.
>
> > [So what did you conclude? I'd think C type casts would be hard to
> > turn into Java unless you made all of storage an opaque block. -John]
>
> Someone else might have thought about the "opaque block" method.
> But that wouldn't work if you wanted to call between Java and C.
>
> As well as I know it, C only requires assignment to work for
> pointers cast to (unsigned char *). And once they are cast,
> usually (though I suppose not always), it is done with memcpy(),
> or compared with memcmp().

Only unsigned char is 100% guaranteed, but on all known systems today
signed char has no trap rep and also works and so does plain char.

> So, all the complication of figuring out what is actually being
> done, can be done inside one of those.
>
> C pointers, then, are an object with a reference to the actual
> array, and current offset within the array, and bounds for
> the array. Pointer arithmetic only changes the offset.
>
> Scalar variables that can be pointed to, compile as arrays
> dimensioned [1].
>
> I didn't get as far as figuring out varargs functions, but someone
> must have done that, as System.out.format() works.
> You can call it with the usual different argument types,
> and it figures out everything.

Java's System.out.format -- and Java's varargs in general -- works
differently than C (at least C as practiced; the standard imposes
enough restrictions you probably _could_ implement it differently).

When Java calls a varargs method, the _caller_ silently creates an
array and fills it with the argument values, alll converted to the one
type specified in the definition (or compiled equivalent), and that
_array_ is actually passed along with the fixed args, in this case the
format string and possibly locale. For this case the one type is
java.lang.Object, which is the top-type for all class _and_ array(1)
instances in Java so they pass unchanged; any primitive value (int,
float, etc) is siliently converted to an instance of a builtin class
(java.lang.Integer, java.lang.Float, etc) by 'autoboxing'. As a result
the format method(2) just matches format specifiers to elements of
that array (remember each Java array instance knows its own length so
subscripting out of bounds traps).

Or more simply, Java varargs is sugar for a homogenous array.

(1) although you can pass an array (as one of the elements of the
silently-created array), the only format specifiers that work on an
item that is an array are %h which prints the hashcode and %s which
prints toString() which is also the hashcode, so not very useful

(2) the PrintStream (and PrintWriter) methods don't do this directly,
they delegate to java.util.Formatter, but same result.

dave_thompson_2@comcast.net writes:
[...]
>> As well as I know it, C only requires assignment to work for
>> pointers cast to (unsigned char *). And once they are cast,
>> usually (though I suppose not always), it is done with memcpy(),
>> or compared with memcmp().
>
> Only unsigned char is 100% guaranteed, but on all known systems today
> signed char has no trap rep and also works and so does plain char.
[...]

The C standard specifically says that signed char has no padding bits
(N1570 6.2.6.2p2).

And plain char has the same representation as either signed char or
unsigned char, so it also has no padding bits.

On the other hand, it's best to use unsigned char to access the
underlying representation. The standard defines the "object
representation" of a value stored in an object in terms of copying it
into an array of unsigned char (N1570 6.2.6.1p4). And C still (until
C23) doesn't mandate 2's-complement for signed types, so that's another
layer of confusion you can avoid by using unsigned char. (all-bits-1
could be a trap representation.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Sunday, January 29, 2023 at 8:57:52 AM UTC-8, dave_th...@comcast.net wrote:
> On Fri, 13 Jan 2023 12:39:41 -0800 (PST), gah4 <ga...@u.washington.edu>

(I wrote)
> > > Some time ago, I was trying to figure out if you could make a C compiler
> > > that generated JVM code. I would run much closer to the C standard
> > > than much C code does, especially regarding casting of pointers.

> > > [So what did you conclude? I'd think C type casts would be hard to
> > > turn into Java unless you made all of storage an opaque block. -John]

> > Someone else might have thought about the "opaque block" method.
> > But that wouldn't work if you wanted to call between Java and C.

> > As well as I know it, C only requires assignment to work for
> > pointers cast to (unsigned char *). And once they are cast,
> > usually (though I suppose not always), it is done with memcpy(),
> > or compared with memcmp().

> Only unsigned char is 100% guaranteed, but on all known systems today
> signed char has no trap rep and also works and so does plain char.

But if the standard says (unsigned char *), and it failed with other types,
would it still be C?

In any case, I would put all the complications into memcpy() and memcmp().

Assignments cast to (unsigned char *) could call memcpy().
Otherwise, they would be assumed to work.

(snip)

> > I didn't get as far as figuring out varargs functions, but someone
> > must have done that, as System.out.format() works.
> > You can call it with the usual different argument types,
> > and it figures out everything.

> Java's System.out.format -- and Java's varargs in general -- works
> differently than C (at least C as practiced; the standard imposes
> enough restrictions you probably _could_ implement it differently).

> When Java calls a varargs method, the _caller_ silently creates an
> array and fills it with the argument values, alll converted to the one
> type specified in the definition (or compiled equivalent), and that
> _array_ is actually passed along with the fixed args, in this case the
> format string and possibly locale. For this case the one type is
> java.lang.Object, which is the top-type for all class _and_ array(1)
> instances in Java so they pass unchanged; any primitive value (int,
> float, etc) is siliently converted to an instance of a builtin class
> (java.lang.Integer, java.lang.Float, etc) by 'autoboxing'. As a result
> the format method(2) just matches format specifiers to elements of
> that array (remember each Java array instance knows its own length so
> subscripting out of bounds traps).

But also, Java didn't always do that automatically.

> Or more simply, Java varargs is sugar for a homogenous array.

I suppose, but it is a lot of sugar!
Having to do the array creating, and all the conversions to fill
the array is a lot of work! And a lot of cases to get wrong.

Some years ago, I was doing Practice it!, which requests you,
in many cases, to write a Java program. The system then compiles
and runs your program, and verifies the output. It mostly makes no
requirement on how you write it. At some point, I started
using System.out.format() for my output statements.

If you want to try it: https://practiceit.cs.washington.edu/

Anyway, yes, that is what I thought Java did with them.
Though some of my programs use arrays dimensioned [1]
instead of the usual wrapper classes.