compiling c

[Folkert van Heusden]

Hello,

For fun I'm writing my own PDP11/70 emulator. I would also like to emulate floating point.

Now I have a problem: I can't get anything compiled under the c-compiler on UNIX7 (nor bsd2.11). I need to do so to be able to create verification data.

My question is: is math.h (and stdio.h) something beyond unix7? And if not: how can I get it on my simh-emulated system? (I'm using simh as a reference as I don't have a real PDP11/70).

The test-program would be:

#include <math.h>
#include <stdio.h>

void emit(double v)
{
int i;
char *p = &v;
for(i=0; i<8; i++)
printf("%02x, ", p[i] & 0xff);
printf("\n");
}

int main()
{
emit(0);
emit(3.14159265358);
emit(-1);
emit(~0);
emit(-(~0));

return 0;
}

[Folkert van Heusden]

Oh that was not k&r c.

The emit-function should look like:

void emit(v)

   double v;

{

... etc

}

[Johnny Billquist]

I don't know Unix 7 enough to say, but what is your problem compiling it
under 2.11BSD?

I just pasted the code in here and compiled and ran it.

simh:/home/bqt> cc testfp.c
testfp.c:7: warning: mixed pointer assignment
simh:/home/bqt> ./a.out
00, 00, 00, 00, 00, 00, 00, 00,
49, 41, da, 0f, 1e, a2, 9f, b7,
80, c0, 00, 00, 00, 00, 00, 00,
80, c0, 00, 00, 00, 00, 00, 00,
80, 40, 00, 00, 00, 00, 00, 00,
simh:/home/bqt>

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Johnny Billquist]

And the same, ran under RSX. Result was slightly different. (This ran on
a real 11/93).

.ccc testfp
.tkb testfp=testfp,clib/lb
.run testfp
00, 00, 7e, 1b, 3e, 30, 3e, ad,

49, 41, da, 0f, 1e, a2, 9f, b7,
80, c0, 00, 00, 00, 00, 00, 00,
80, c0, 00, 00, 00, 00, 00, 00,
80, 40, 00, 00, 00, 00, 00, 00,

.

I find it kindof weird that C generates that pattern for a true 0, but I
guess it's technically just fine.

Johnny

[Heinz-Bernd Eggenstein]

>I find it kindof weird that C generates that pattern for a true 0, but I
>guess it's technically just fine.

I get a similar weird result with an older version of 2.11BSD that still has the K&R C compiler (before the patch that kind-of-ANSI-fied the compiler):

hbeggenstein [53] cc -o test test.c -lm
test.c:8: warning: mixed pointer assignment
hbeggenstein [54] ./test
00, 00, 46, 8b, 64, 8b, 14, 8a,

49, 41, da, 0f, 1e, a2, 9f, b7,

ff, ff, 46, 8b, 64, 8b, 14, 8a,
ff, ff, 46, 8b, 64, 8b, 14, 8a,
01, 00, 46, 8b, 64, 8b, 14, 8a,
hbeggenstein [55]

Where the bytes 3..8 in the first output line are basically random.

I guess what happens is that emit(0) will put the 16 bit integer 0x0000 on the stack , 

but emit() will read an 8 byte double from the stack , so 6 extra bytes of pure rubbish :-)

AFAIK K&R C has a build-in rule that it will convert any float to a double before passing 

it as argument to any function, but it is not smart enough to know here that emit expects 

a double that the integer 0 will need to be converted to in the first place.

If you instead call

emit(0.0);

the output will be 8 times 00 as expected.

To me this demonstrates how "semi-broken" C, or at least these implementation,  were before ANSI C. 

Also the rule that floats are almost  always converted to doubles except for storage in arrays or structs 

etc makes them much less useful, e.g. you don't have a speed advantage by doing calculations which 

floats because they are always converted to doubles!

You can even call emit() with extra arguments without the K&R compiler complaining!!

E.g. 

emit(0,2,4,6);

will produce the output (you guessed it...)

00, 00, 02, 00, 04, 00, 06, 00,

With the latest ANSI-like-C on  2.11BSD, cc will finally reject to compile this:

hbeggenstein [8] cc test.c -o test -lm
test.c:7: warning: mixed pointer assignment
test.c:15: warning: illegal combination of pointer and integer
test.c:15: Disallowed conversion
test.c:15: Disallowed conversion
test.c:15: call do not match prototype

Cheers

HB

[Anton Lavrentiev]

I suppose that you have you to use a floating point notation when calling emit(), because old C compilers didn't use prototypes (no types, nor the number of arguments were attached to the function names), and went by the actual parameters passed to functions. If anything shorter than int was passed, it'd be a 16-bit quantity pushed onto the stack, 4 bytes were pushed for long, if it was a float, then it'd be an 8-byte value pushed (floats always convert to double).  We still see these conventions in ANSI C for vararg functions, such as printf().  That's basically why prototypes were added to the language, to avoid this confusion what a function actually expects, and do the correct type conversion at the time of the call, if necessary.

So rewrite those as emit(0.0), emit(-1.0), emit((double)(~0)), etc...  I hope that fixes the issue you're observing.

HTH,

Anton 

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/d6a41968-3005-4d0a-b417-1505d4812ac5n%40googlegroups.com.

[Johnny Billquist]

Well, it's also the fact that a float with an exponent of absolute zero
is always considered to be a true zero, no matter what the mantissa
says, so technically a compiler can put whatever in there, and it's
still correct.

So if you get a 16 bit zero, it's just as good as putting in a full 8
bytes. So technically, you could even say that it's more optimized.

I looked at the generated code for current 2.11BSD, and it actually
generates a "clrf -(sp)" for the zero, so it actually directly push the
value on the stack for the call, and takes advantage of the fact that
the fpp can generate a full zero on its own without having the compiler
create a constant for it somewhere first.

DEC PDP-11 C (and I assume other older versions you looked at) actually
generates a constant in the code, and that constant is then pushed on
the stack, with no special casing for zero. So then it becomes a
question of when the compiler generates as a constant for a floating 0.

The code from PDP-11 C looks like this:

.PSECT
$CONST,RO,D,LCL,REL,CON
$CONST:
000000 040200 000000 000000 .FLT4 1.
000000 000000
000010 140200 000000 000000 .FLT4 -1.
000010 000000
000020 000000 015576 064636 .FLT4 0.
000020 126476
000030 040511 007732 121036 .FLT4 3.14159265358
000030 133637


However, if actually doing that in MACRO-11, I get:

3 000000 000000 000000 000000 X: .FLT4 0.
000006 000000


So that is some "funny" think in the C compiler. But, like I said,
technically, but are equally valid floating point zeros.

Johnny

> >> emit(3.14159265358 <tel:(415)%20926-5358>);

> >> emit(-1);
> >> emit(~0);
> >> emit(-(~0));
> >>
> >> return 0;
> >> }
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "[PiDP-11]" group.
> >> To unsubscribe from this group and stop receiving emails from
> it, send
> >> an email to pidp-11+u...@googlegroups.com
> >> <mailto:pidp-11+u...@googlegroups.com>.
> >> To view this discussion on the web visit
> >>

> https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com <https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com> <https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/pidp-11/CAHwprn1c3sAyZF540KfLO_J6KMSLjq%2B-9uGhxf-4fEfXEs4JYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

> >
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: b...@softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/d6a41968-3005-4d0a-b417-1505d4812ac5n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/d6a41968-3005-4d0a-b417-1505d4812ac5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[terry-...@glaver.org]

On Tuesday, June 18, 2024 at 8:35:55 PM UTC-4 hbep...@googlemail.com wrote:

To me this demonstrates how "semi-broken" C, or at least these implementation,  were before ANSI C.

I corresponded semi-regularly with DMR before his passing, originally to ask him for the source for "festoon". I eventually collected many of the things he wrote for fun. One of them was "astro". The same code compiled without errors on (at least) PDP-11/2.11BSD, VAX/VMS, PC/Windows, Raspberry Pi, x86/Linux/gcc, x64/FreeBSD/clang. Producing different output on all of them. A bunch of us spent time trying to track down the problem, including poring over listings of the generated assembler code, consulting hardcopy tables to determine the correct output. I filed a LLVM bug on clang because DMR's code couldn't possibly be wrong, right?

It turns out it was in such an obscure, ancient dialect of C that it was full of undefined behavior.

Since then, FreeBSD has added a "Plan 9 from User Space"  port that includes many of these utilities, cleaned up to work with modern-ish compilers.

[Johnny Billquist]

A few more comments, I guess.

On 2024-06-19 02:35, 'Heinz-Bernd Eggenstein' via [PiDP-11] wrote:

Why would that be "expected". Both values are equally correct 0.0
floating point values. One should never make assumptions about how this
might be represented by the hardware, because that might be very
different for every architecture you are on. The moment you go under the
hood and start poking at things at this level, you are outside every
expectation.

Again - any floating point value with all zeroes in the exponent on a
PDP-11 is a floating value of 0.0, no matter what the mantissa say. And
doing floating point operations like comparing or doing arithmetics on
it will produce the correct, expected results.
And one of the reasons for this is that you always have a hidden one in
any normal floating point value, so you can't actually have a mantissa
of true zero ever. So true zero really have to be special cased.

When getting down to this level, you really need to understand how the
hardware works before making any comments on wether the C compiler is
doing a thing correct or not.

> To me this demonstrates how "semi-broken" C, or at least these
> implementation,  were before ANSI C.

In this case, I completely fail to see that. The compiler generates code
that is a correct 0.0 value in all of the cases we looked at. Nothing is
broken, nothing is wrong.

It's just you who have a problem with some bits that are irrelevant are
not set to a value that you think they should be.

> Also the rule that floats are almost  always converted to doubles except
> for storage in arrays or structs
> etc makes them much less useful, e.g. you don't have a speed advantage
> by doing calculations which
> floats because they are always converted to doubles!

Just as any kind of shorter ints are always promoted to ints in some
situations.
Yes, the only gains are in using less memory. Any potential speed
advantage of using floats are just not there.

> You can even call emit() with extra arguments without the K&R compiler
> complaining!!
> E.g.
> emit(0,2,4,6);
> will produce the output (you guessed it...)
> 00, 00, 02, 00, 04, 00, 06, 00,

Yes, that's a result of there being absolutely no checking of arguments
in K&R C. But you seem to demontrate that emit actually would make use
of all arguments actually given. Now you got me curious, because C have
no way of telling how many arguments were actually given. So I wonder
how on earth that works... My expectation would have been that it would
only have processed the first argument and ignored all the rest.

Sadly, the only K&R C compiler I have around is DECUS C for RSX, so I
can't easily check how thinks work or behave on older Unix with a K&R C.

> With the latest ANSI-like-C on  2.11BSD, cc will finally reject to
> compile this:
>
> hbeggenstein [8] cc test.c -o test -lm
> test.c:7: warning: mixed pointer assignment
> test.c:15: warning: illegal combination of pointer and integer
> test.c:15: Disallowed conversion
> test.c:15: Disallowed conversion
> test.c:15: call do not match prototype

Was that with some different code then? Because I compiled the test
program under 2.11BSD and I got the mixed pointer assignment warning
about line 7, but none of the other things.


As for undefined behaviour in C, brokenness and all that. People tend to
forget that this is the case with any language. It's just that few exist
on as many platforms as C. ANSI did in some way make things better, but
they also made it worse.
When ANSI formalised a lot of things around C, they also formalised
things around undefined or implementation defined behaviours, and
compiler writers have become extremely clever at making use of these
cases to do all kind of weird things in optimizations, making code that
once worked fine suddenly not work anymore, just because ANSI allows the
implementors to do anything in lots of cases. Things which people in the
past just expected to work right because it just was the very sensible
thing to expect. The way ANSI allows compilers to optimize and change
code means it's actually becoming harder to write useful code in C
(weirdly enough).

Johnny

[Heinz-Bernd Eggenstein]

>Was that with some different code then? Because I compiled the test
>program under 2.11BSD and I got the mixed pointer assignment warning

>about line 7, but none of the other things.

This was in reference to the discussion what happens when you call emit with more than one (integer) arguments. So it's the original code from the thread starter just with emit(0); replaced by emit(0,2,4,6);

Note that this is the ANSI-C version of the code (1st message in the thread), not the K&R version from the second message in the thread...if we want to demonstrate the difference between the ANSI and K&R version of the compilers, I think it's the fair comparison. ANSI-C vs. K&R C.

> It's just you who have a problem with some bits that are irrelevant are
> not set to a value that you think they should be.

The fact that a double with the first 16 bits set to zero is a legal representation of the double 0.0 irrespective of the other bits is, IMHO,  just a lucky coincidence here, it's not like the compiler is smart enough to optimize this there.

> But you seem to demontrate that emit actually would make use
>of all arguments actually given. Now you got me curious, because C have
>no way of telling how many arguments were actually given. So I wonder
>how on earth that works... My expectation would have been that it would
>only have processed the first argument and ignored all the rest.

IMHO, the code implementing the function will just grab 8 bytes from the stack and treat them as a double, and the code that is calling emit in the K&R version will just push whatever you give it as an argument on the stack, no matter of type, but might use a special instruction for "0" or "0.0" values as optimization. But not because it knowns that it will not matter because of the special way zero is represented in PDP-11 doubles: at that point the K&R compiler is not aware of what emit is expecting as an argument type, so it cannot optimize for it. It just pushes *any type*, and *any number* of arguments to the stack and then calls the function. No Checks, no type conversion. And yes, this is correct as K&R doesn't claim to do anything else, but we might argue whether this is what people (like the thread starter) expect to happen.

And yes, I use "expect" here in a totally subjective way, as in "what I think will happen, intuitively", and not in a normative way "what I think should happen according to the book". Expectations can be right or wrong. Sorry that was a bit sloppy in my message.

P.S.:
I think one legitimate objection to the "semi-broken" thing tho might be the following: in K&R times, nobody would just trust the C compiler to produce "good" code or the code you wanted/expected, you would also run "lint" across your code.

And sure enough, 2.11BSD lint from K&R times will complain that

emit(0);

and all the other calls of emit from the thread starter's example code  except the one with pi is "arg. 1 used inconsistently".

If you change that to

emit(0.0,1.0);

lint will warn you about "variable # of args"

In the words of "K&R" : "Existing compilers provide no run-time checking of array-subscripts, argument types, etc.    For those situations where strong type checking is desirable, a sepearate version of the compiler is used. This program is called lint, apparently because it picks bits of fluff from one's programs. lint does not generate code.[...]"

Maybe we can agree on this?

Cheers

HB

[Johnny Billquist]

On 2024-06-23 16:02, 'Heinz-Bernd Eggenstein' via [PiDP-11] wrote:
> >Was that with some different code then? Because I compiled the test
> >program under 2.11BSD and I got the mixed pointer assignment warning
> >about line 7, but none of the other things.
>
> This was in reference to the discussion what happens when you call emit
> with more than one (integer) arguments. So it's the original code from
> the thread starter just with emit(0); replaced by emit(0,2,4,6);
> Note that this is the ANSI-C version of the code (1st message in the
> thread), not the K&R version from the second message in the thread...if
> we want to demonstrate the difference between the ANSI and K&R version
> of the compilers, I think it's the fair comparison. ANSI-C vs. K&R C.

Ah. Yeah, I would expect the compiler to barf in ANSI C if you throw the
wrong number of arguments on it. :-)

> > It's just you who have a problem with some bits that are irrelevant are
> > not set to a value that you think they should be.
>
> The fact that a double with the first 16 bits set to zero is a legal
> representation of the double 0.0 irrespective of the other bits is,
> IMHO,  just a lucky coincidence here, it's not like the compiler is
> smart enough to optimize this there.

I agree that the compiler isn't smart enough to optimize this. Because
the compiler have no clue that the emit() function expects a floating
point. I would sortof disagree that it's a lucky coincidence that it
would out correctly for 0, though. I would suspect it was a conscious
choice by the designers of the hardware. There are times when this can
be used to do shortcuts in code.

> > But you seem to demontrate that emit actually would make use
> >of all arguments actually given. Now you got me curious, because C have
> >no way of telling how many arguments were actually given. So I wonder
> >how on earth that works... My expectation would have been that it would
> >only have processed the first argument and ignored all the rest.
>
> IMHO, the code implementing the function will just grab 8 bytes from the
> stack and treat them as a double, and the code that is calling emit in
> the K&R version will just push whatever you give it as an argument on
> the stack, no matter of type, but might use a special instruction for
> "0" or "0.0" values as optimization. But not because it knowns that it
> will not matter because of the special way zero is represented in PDP-11
> doubles: at that point the K&R compiler is not aware of what emit is
> expecting as an argument type, so it cannot optimize for it. It just
> pushes *any type*, and *any number* of arguments to the stack and then
> calls the function. No Checks, no type conversion. And yes, this is
> correct as K&R doesn't claim to do anything else, but we might argue
> whether this is what people (like the thread starter) expect to happen.

Ah. Very good point. Yes, I think that is very correct. The code just
grabs the top 8 bytes, which in the case of multiple arguments just
happens to would out that way.

Thing is, though. Because of how data is represented on the PDP-11, this
means that for a 0, it will work correctly both for integer and floating
point, without any additional tricks. Which is very convenient and nice.

The end result is that you, when you write code, expects to get a zero,
and you are getting that. So it does what you expect it to do. And it
accomplish it without having to do any type checks or type conversions
or anything.

I think it's wrong to expect bits that are not relevant should have some
specific value in them, though.

And yes, the calling side just push whatever arguments you give, without
any understanding what the called side will do with the arguments, or
how to interpret them. With K&R C, that is a mental contract of the
programmer to which the compiler do not provide any assistance.

But the PDP-11 architecture itself defines a floating 0.0 as identical
to a integer 0, looking at the same address for the data, and that have
nice implications.

But clearly the compiler have no actual clue what you are doing, which
is why, in the K&R compiler, you get bad results for all the other cases
where you give an integer.

Which means you do not get what you expect for non-zero values, unless
you make sure they are of the correct type yourself.

> And yes, I use "expect" here in a totally subjective way, as in "what I
> think will happen, intuitively", and not in a normative way "what I
> think should happen according to the book". Expectations can be right or
> wrong. Sorry that was a bit sloppy in my message.

For me, I expect it to be "correct" in the sense that the operations and
results are the ones I would expect. Non-relevant bits are not something
I have any expectation on. And C is usually very liberal about leaving
such bits and bytes with all kind of random content.

I might have been focusing too much on the 0 case here though. Clearly
for any other values, you are not getting what you might have expected.
Which is just because the compiler isn't smart at all. The designers of
the architecure "saved" you for the 0 case, and the mantissa bits are
clearly allowed to be anything. So all is good there. And I don't see
any reason to complain about anything around that bit.

But you are correct in that K&R C will give you bad results in most
cases if you give the wrong type of arguments to a function call, and
the compiler neither fix things, nor warn you.

> P.S.:
> I think one legitimate objection to the "semi-broken" thing tho might be
> the following: in K&R times, nobody would just trust the C compiler to
> produce "good" code or the code you wanted/expected, you would also run
> "lint" across your code.
>
> And sure enough, 2.11BSD lint from K&R times will complain that
> emit(0);
> and all the other calls of emit from the thread starter's example code
> except the one with pi is "arg. 1 used inconsistently".
>
> If you change that to
> emit(0.0,1.0);
> lint will warn you about "variable # of args"

lint was usually the tool to check for these kind of "bugs", yes.

> In the words of "K&R" : "Existing compilers provide no run-time checking
> of array-subscripts, argument types, etc.    For those situations where
> strong type checking is desirable, a sepearate version of the compiler
> is used. This program is called lint, apparently because it picks bits
> of fluff from one's programs. lint does not generate code.[...]"

I wouldn't even call lint a compiler. :-)

> Maybe we can agree on this?

For sure.

[Johnny Billquist]

On 2024-06-23 17:47, Johnny Billquist wrote:
> On 2024-06-23 16:02, 'Heinz-Bernd Eggenstein' via [PiDP-11] wrote:
>>  >Was that with some different code then? Because I compiled the test
>>  >program under 2.11BSD and I got the mixed pointer assignment warning
>>  >about line 7, but none of the other things.
>>
>> This was in reference to the discussion what happens when you call
>> emit with more than one (integer) arguments. So it's the original code
>> from the thread starter just with emit(0); replaced by emit(0,2,4,6);
>> Note that this is the ANSI-C version of the code (1st message in the
>> thread), not the K&R version from the second message in the
>> thread...if we want to demonstrate the difference between the ANSI and
>> K&R version of the compilers, I think it's the fair comparison. ANSI-C
>> vs. K&R C.
>
> Ah. Yeah, I would expect the compiler to barf in ANSI C if you throw the
> wrong number of arguments on it. :-)

By the way, ANSI C still have the same issue and story, if you use
varargs. Then we're back to K&R situation again. Just pointing that out...

[Rob Pike]

Astro was written by Ken Thompson, not Dennis.

-rob

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/f6f0c1cf-8925-4b6e-83fa-d62a6c25fe6dn%40googlegroups.com.

[terry-...@glaver.org]

I stand (or sit at the feet of giants 8-) corrected. It was one of the things I asked Dennis for, and he sent me a few tarballs. Most had been Plan 9-ified and he no longer had the original "classic UNIX" source versions for many of them handy.

[Rob Pike]

No problem, Dennis gets a lot of credit for things others did. It's a hazard of being the most famous person in the room, and a reason I learned always to credit others when sharing something.

Anyway, there is a working version of astro in the plan9port distribution, which compiles and runs fine on Linux or Macs.

https://9fans.github.io/plan9port/

-rob

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/6183ba81-5960-432a-9000-48b32d1cba00n%40googlegroups.com.