Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #3270 > unrolled thread

Compilers :)

Back to article view | Back to comp.compilers

Contents

  Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-02 12:28 +0200
    Re: Compilers :) Spiros Bousbouras <spibou@gmail.com> - 2023-01-02 20:52 +0000
      Re: another C-like language? was Compilers :) Steve Limb <stephenjohnlimb@gmail.com> - 2023-01-03 16:24 +0000
        Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-03 12:52 -0800
          Re: another C-like language? was Compilers :) arnold@skeeve.com (Aharon Robbins) - 2023-01-04 17:12 +0000
            Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-04 12:39 -0800
        Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-05 06:27 -0800
          Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-05 16:26 -0800
          Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-06 15:39 +0100
            Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-09 17:41 +0000
              Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-10 17:48 +0100
                Re: another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-10 15:13 -0800
                  Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-11 13:38 +0100
                    Re: back in the 60s, another C-like language? was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-11 16:38 -0800
                    Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:26 -0800
                Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-11 11:02 +0000
                  Re: Scheme is not another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-12 02:54 -0500
                Re: another C-like language? was Compilers :) Bill Findlay <findlaybill@blueyonder.co.uk> - 2023-01-11 11:58 +0000
              Re: another C-like language? was Compilers :) Thomas Koenig <tkoenig@netcologne.de> - 2023-01-11 10:49 +0000
                Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-15 04:21 -0800
                  Re: another C-like language? was Compilers :) Andy Walker <anw@cuboid.co.uk> - 2023-01-15 22:01 +0000
              Re: another C-like language? was Compilers :) "Luke A. Guest" <laguest@archeia.com> - 2023-01-13 18:25 +0000
                Re: another C-like language? was Compilers :) George Neuner <gneuner2@comcast.net> - 2023-01-13 17:20 -0500
                Re: another C-like language? was Compilers :) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-14 19:07 +0000
          Re: another C-like language? was Compilers :) "marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> - 2023-01-07 02:14 -0800
            Re: another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-08 20:21 +0100
              Re: another C-like language? was Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-09 04:48 +0100
                Re: C scopes, another C-like language? was Compilers :) David Brown <david.brown@hesbynett.no> - 2023-01-09 18:12 +0100
              Re: another C-like language? was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-09 11:24 -0800
      Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 13:41 +0200
    Re: Compilers :) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-01-05 01:12 +0100
      Re: Compilers :) "Tristan B. Velloza Kildaire" <deavmi@redxen.eu> - 2023-01-13 14:17 +0200
        Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 10:32 -0800
          Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-13 12:39 -0800
            Re: C and Java, was Compilers :) dave_thompson_2@comcast.net - 2023-01-28 10:37 -0500
              Re: C and archtecture, C and Java, was Compilers :) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 19:37 -0800
              Re: C and Java, was Compilers :) gah4 <gah4@u.washington.edu> - 2023-01-29 21:39 -0800

Page 2 of 2 — ← Prev page 1 [2]

#3329 — Re: another C-like language? was Compilers :)

On 15/01/2023 12:21, marb...@yahoo.co.uk wrote:
> [...] I gather it took 6 years to write the first
> complete A68 compiler! Well, strictly speaking, they'd revised A68 by
> then, so it was an A68R compiler.

	A68-R was announced in July 1970, so much less than 6 years
from the A68 Report [December 1968].  It wasn't entirely a complete
compiler, having a few changes primarily to permit single-pass
compilation [but also, eg, "CODE ... EDOC" brackets for embedded
machine code].  Nothing to do with the Revised Report, which was
several years later, and incorporated the experience of A68-R.  It
also took much less than 6 years from the publication of the RR to
the first compilers.

--
Andy Walker, Nottingham.
    Andy's music pages: www.cuboid.me.uk/andy/Music
    Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Byrd

[toc] | [prev] | [next] | [standalone]

#3320 — Re: another C-like language? was Compilers :)

On 09/01/2023 17:41, Kaz Kylheku wrote:
> On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
>> don't want to go through them all, but I agree with you that the style
>> of "all your declarations at the start of the function" is long
>> outdated, and often - but not universally - considered a bad idea.)
>
> Declarations have never been required to be at the top of a function in
> C, because they can be in any compound statement block. I think
> that goes all the way back to the B language. [Nope, see the next message. -John]

When I learnt C, you had to define your variables at the top of the
block {} whether that's a function or a block within the function somewhere.

> The "Variables at the top" meme may be something coming from Pascal.

Nope. Algol. C is an Algol derived language.

> IIRC, in Pascal, compound statements aren't full blocks; they cannot
> have VAR declarations.
>
> When programmers abandoned Pascal in the 1980s, they carried over this
> habit into C.

Nope, this was defined in the C spec and the K&R book. Apparently this
has been relaxed recently-ish and now variables can be defined anywhere.

[toc] | [prev] | [next] | [standalone]

#3324 — Re: another C-like language? was Compilers :)

On Fri, 13 Jan 2023 18:25:37 +0000, "Luke A. Guest"
<laguest@archeia.com> wrote:

> C is an Algol derived language.

Well ... Algol influenced in any case, through B.
[Rather indirectly.  C is derived from B which was a
stripped down version of BCPL which was a boostrap
subset of CPL which was designed in the early 1960s
with influence from Algol.  See Wikipedia. -John]

[toc] | [prev] | [next] | [standalone]

#3325 — Re: another C-like language? was Compilers :)

On 2023-01-13, Luke A. Guest <laguest@archeia.com> wrote:
> On 09/01/2023 17:41, Kaz Kylheku wrote:
>> On 2023-01-06, David Brown <david.brown@hesbynett.no> wrote:
>>> don't want to go through them all, but I agree with you that the style
>>> of "all your declarations at the start of the function" is long
>>> outdated, and often - but not universally - considered a bad idea.)
>>
>> Declarations have never been required to be at the top of a function in
>> C, because they can be in any compound statement block. I think
>> that goes all the way back to the B language. [Nope, see the next message. -John]
>
> When I learnt C, you had to define your variables at the top of the
> block {} whether that's a function or a block within the function somewhere.

Well yes; that is the situation in ISO C 90. ISO C 99 introduced mixed
declarations and statements. Or, perhaps we should say, the C++ dialect
introduced this (and standardized it first, in 1998).

>> The "Variables at the top" meme may be something coming from Pascal.
>
> Nope. Algol. C is an Algol derived language.
>
>> IIRC, in Pascal, compound statements aren't full blocks; they cannot
>> have VAR declarations.
>>
>> When programmers abandoned Pascal in the 1980s, they carried over this
>> habit into C.
>
> Nope, this was defined in the C spec and the K&R book. Apparently this
> has been relaxed recently-ish and now variables can be defined anywhere.

The discussion is about whether variables must be declared at the top of
the entire function, even if it has nested compound statements where
some of them could be declared.

The top-of-function restriction exists in Pascal; compound statements
do not have VAR section.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[Algol60 allowed declarations at the start of every block, so I think
it was one of the things Pascal left out to make it easier to compile.
It does make one-pass compiling with tiny memory easier.  These days,
that's irrelevant. -John]

[toc] | [prev] | [next] | [standalone]

#3289 — Re: another C-like language? was Compilers :)

> [If you're doing a one-pass compiler, it's easier if all the declarations are at the
> beginning so you can generate the code to set up the stack frame and do initializations.
> I agree that on modern computers it's not a big deal, but remember that early C compilers
> ran in 24K bytes and I don't mean meagabytes. -John]

Presumably such a compiler would have to create 2 stack frames for
`char *foo="foo"; puts(foo); { char *bar="bar"; puts(bar); }`
[In a mutant version of C with nested scopes, I suppose so, but when C compilers
ran in 24K bytes, it didn't. -John]

[toc] | [prev] | [next] | [standalone]

#3292 — Re: another C-like language? was Compilers :)

On 07/01/2023 11:14, marb...@yahoo.co.uk wrote:
>> [If you're doing a one-pass compiler, it's easier if all the declarations are at the
>> beginning so you can generate the code to set up the stack frame and do initializations.
>> I agree that on modern computers it's not a big deal, but remember that early C compilers
>> ran in 24K bytes and I don't mean meagabytes. -John]
>
> Presumably such a compiler would have to create 2 stack frames for
> `char *foo="foo"; puts(foo); { char *bar="bar"; puts(bar); }`

No.  The compiler could treat this as though you had written :

	char *foo = "foo";
	char *bar_nested_scope_1;

	puts(foo);
	{
		bar_nested_scope_1 = "bar";
		puts(bar);
	}

In other words, it can combine all the variables declared in nested
scope and act as though they were all defined at the start of the
function.  It would have to take care of naming, as nested block scopes
could have identifiers that shadow outer scope names.  And it may or may
not choose to allow overlapping of variables that have independent
lifetimes.

It only gets complicated when you have variable length arrays, which
would allow the declaration of an array whose size is not known at the
start of the function.  But if you are supporting VLA's, you'll already
have support for more sophisticated mixes of variables and code.

> [In a mutant version of C with nested scopes, I suppose so, but when C compilers
> ran in 24K bytes, it didn't. -John]

I don't have my copy of K&R handy, or a pre-K&R Unix C manuals, but I
expect someone will correct me if I'm wrong :-)  As far as I know, the C
described in "The C Programming Language" in 1978, when 24 KB was still
a big deal, supported declarations at the start of any compound
statement block.  That is, nested scopes.  It's possible that pre-K&R C
compilers were more limited.
[I actually used that 24K C compiler in about 1975 and I am reasonably sure
it did not let you put declarations other than in the outer block.  There's
a 1978 edition of K&R at archive.org and by then it did let you put
declarations in any block.  It's a little harder than what you say because
declarations in non-overlapping blocks should overlay each other, e.g.:

foo() {
  int a:
  ...
  {
     int b[100];
     somefunc(b);
  }
  {
     float c[100];
     otherfunc(c);
  }
}

you want b and c to use the same storage.  It's not hard, but it's a little
more than promoting and renaming. -John]

[toc] | [prev] | [next] | [standalone]

#3293 — Re: another C-like language? was Compilers :)

On 1/8/23 8:21 PM, David Brown wrote:

> In other words, it can combine all the variables declared in nested
> scope and act as though they were all defined at the start of the
> function.

AFAIR nested scopes were introduced just to allow for space saving
memory overlays. Regardless of whether a compiler really takes that
optimization *option*.

Of course problems can arise from malware assuming memory contents as
left over from a previous block, as it's not required that the compiler
initializes all local variables on block entry.

DoDi

[toc] | [prev] | [next] | [standalone]

#3296 — Re: C scopes, another C-like language? was Compilers :)

On 09/01/2023 04:48, Hans-Peter Diettrich wrote:
> On 1/8/23 8:21 PM, David Brown wrote:
>
>> In other words, it can combine all the variables declared in nested
>> scope and act as though they were all defined at the start of the
>> function.
>
> AFAIR nested scopes were introduced just to allow for space saving
> memory overlays. Regardless of whether a compiler really takes that
> optimization *option*.

I don't know the history as to /why/ block scope variables were
introduced in C - that was all before my time.  But they certainly allow
you to write better structure in your code (in my opinion, anyway - I am
aware that some people think "declare all variables at the start of the
function before any code" gives better code).  IMHO, local variables
should have as small a scope as practically possible.  So even if I have
to use C90 (which I dislike - C99 was a big improvement), if I have a
variable that is only needed inside a loop or a conditional, I'll
declare it there.

Compilers have always been free to use lifetime analysis to merge or
overlap variables, regardless of how and where they are declared inside
a function.  There have never been any requirements from the language
forcing compilers to have separate "stack slots" for variables that are
declared at the start of a function or within the same block.  Of
course, compilers of old were not as sophisticated as modern compilers,
and debuggers of old were also more limited, so it was quite common to
have fixed and dedicated stack slots for each variable declared at the
start of the function.  But it was never /required/ for correct
implementation of the language.

> Of course problems can arise from malware assuming memory contents as
> left over from a previous block, as it's not required that the compiler
> initializes all local variables on block entry.
>

You are required to initialise or assign to all local variables that you
read.  Failing to do so is undefined behaviour (or in some
circumstances, unspecified behaviour).  And it doesn't matter whether
you initialise your local variable at the start of a block, or assign to
it later when you use it - the compiler is under no obligation to make
any initialisation at the start of the block, regardless of what you
write.  It only has to make sure you get the same results in the end as
you would have had if it had followed your source code directly.

If malware can execute its code inside your functions (from code
injections, buffer overflows, etc.), then all sorts of things can go
wrong.  Initialising local variables at the start of a block can reduce
the risks and consequences a bit, but it will not save you.

[toc] | [prev] | [next] | [standalone]

#3298 — Re: another C-like language? was Compilers :)

David Brown <david.brown@hesbynett.no> writes:
[...]
>> [In a mutant version of C with nested scopes, I suppose so, but when C compilers
>> ran in 24K bytes, it didn't. -John]
>
> I don't have my copy of K&R handy, or a pre-K&R Unix C manuals, but I
> expect someone will correct me if I'm wrong :-)  As far as I know, the C
> described in "The C Programming Language" in 1978, when 24 KB was still
> a big deal, supported declarations at the start of any compound
> statement block.  That is, nested scopes.  It's possible that pre-K&R C
> compilers were more limited.
> [I actually used that 24K C compiler in about 1975 and I am reasonably sure
> it did not let you put declarations other than in the outer block.  There's
> a 1978 edition of K&R at archive.org and by then it did let you put
> declarations in any block.  It's a little harder than what you say because
> declarations in non-overlapping blocks should overlay each other, e.g.:
>
> foo() {
>  int a:
>  ...
>  {
>     int b[100];
>     somefunc(b);
>  }
>  {
>     float c[100];
>     otherfunc(c);
>  }
> }
>
> you want b and c to use the same storage.  It's not hard, but it's a little
> more than promoting and renaming. -John]

The 1975 C reference manual <https://www.bell-labs.com/usr/dmr/www/cman.pdf>
allows declarations at the top of a function body but not at the top of
a compound statement.  K&R1 (1978) does allow declarations at the top of
a compound statement.

In the example above, you'd certainly *want* b and c to use the same
storage, but the language doesn't require it.  But it's a simple enough
optimization that I'd expect all compilers to do it (or something more
sophisticated).  Also, a compiler could either generate code that
allocates storage for each block on entry to the block, or that
allocates the maximum size on entry to the function.  I haven't bothered
to look into what compilers actually do.  (And it gets more complicated
if you introduce variable-length arrays.)

--
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 a PDP-11 or Vax, adjusting the size of local storage was a single
instruction to adjust the stack pointer at the entry to or exit from
each block. In the example above, imagine that between the two blocks
is a call to bloatfunc() which has a large stack frame and you can see
why it would have been worth it.  I will admit that if you had goto
statements, that made it considerably messier. -John]

[toc] | [prev] | [next] | [standalone]

#3318

On 2023/01/02 22:52, Spiros Bousbouras wrote:
>> I plan to, by
>> the end of 2023 hopefully, have a full release out. The code emit is
>> already working well and so is the dependency tree algorithmn.
>
> Code emitter for what targets ?

Code emitter emits C currently, so whatever your C compiler can target

[toc] | [prev] | [next] | [standalone]

#3276

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]

[toc] | [prev] | [next] | [standalone]

#3319

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).

[toc] | [prev] | [next] | [standalone]

#3321 — Re: C and Java, was Compilers :)

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]

[toc] | [prev] | [next] | [standalone]

#3322 — Re: C and Java, was Compilers :)

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.

[toc] | [prev] | [next] | [standalone]

#3345 — Re: C and Java, was Compilers :)

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.

[toc] | [prev] | [next] | [standalone]

#3348 — Re: C and archtecture, C and Java, was Compilers :)

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 */

[toc] | [prev] | [next] | [standalone]

#3349 — Re: C and Java, was Compilers :)

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.compilers

csiph-web