On 2013-01-16 21:17, Steve Davidson wrote:
The PDP-11 "C" compiler was a buyout. It started life out as a PASCAL compiler. The first project leader (J. Bishop) works for Intel - on the West Coast.
I believe that to be incorrect.
I had to search through my archives of stuff, to check, as it didn't match my hazy memories.
The project leader for the DEC PDP-11 C compiler was Thomas Krupinski, and he was the project leader all the way from the beginning to the end. And it was never a PASCAL compiler, nor did it start outside of DEC.
Here is excerpts from a conversation I had with him a number of years ago:
***
> I wouldn't be surprised if DEC C was written in MACRO-11. I very much
> doubt DECUS C was involved anyway.
I suspect you are referring to Digital's PDP-11 C. A
couple years before this project was begun, an
engineer was tasked with investigating if it would be
feasable to "productize" DECUS C. The engineer
concluded it wasn't. PDP-11 C is written mostly in C,
with a very small amount of code written in MACRO-11.
The compiler compiles itself for the RT-11, RSX and
RSTS/E versions, and is compiled by VAXC (PDP-11C
preceeded DEC C) for a cross compiler running on VMS
and producing PDP-11 code. The compiler will produce
either .obj files or MACRO-11 (or both). The latter
was useful when a member of the RSTS/E group
implemented a CUSP in PDP-11 C while it was still in
beta - Management wouldn't let him release it since it
was compiled with an unreleased product (strange, that
never stopped folks from releasing code written using
the BLISS-11 compiler), so he simply compiled it to
MACRO-11, and checked that in, since MACRO-11 was
supported...
> none used DECUS C as a bootstrap as far as I know.
I can confirm that PDP-11 C did not bootstrap using
DECUS C.
Tom Krupinski
Project leader for PDP-11 C V1.0, V1.1, V1.2
(And the engineer who did the DECUS C investigation)
***
I have not talked with him in ages now...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-01-16 21:26, Steve Davidson wrote:
Is their a version of PCC that could generate PDP-11 assembly code?
Generating assembly code is only half of the problem. To compile and run this thing, you also need enough parts of a C library to make it work, and matching calling conventions between your compiled code and that C library...
Johnny
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of John Wilson
Sent: Tue 1/15/2013 21:46
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Benchmarks - WHETSTONE.C
On Tue, Jan 15, 2013 at 05:56:33PM +0100, Johnny Billquist wrote:
That it would... Anyone have GCC setup to generate something that can
be linked under RSX?
That's a tall order (adding .OBJ to binutils?) ... and lately I think GCC for
PDP-11s is pretty badly broken. I built the (then-)latest GCC to cross-compile
for PDP-11s a few weeks ago (working on porting Conticki) and it's pretty
broken -- stack frames get all tangled up on any function with >2 locals.
Turning off frame pointers or enabling optimization just makes it worse.
I did a temporary hack which got it generating seemingly correct (but *awful*)
code, but I didn't understand how it worked well enough to really fix it. It
seems like it's trying to keep track of modifications to SP but apparently on
*any* modification it assumes that it's lost track of the top of the stack
(even if the modification was push and then pop, i.e. no net change) and tries
to dig its way out with the frame pointer (which it gets off by a word).
But anyway ... I would think a GAS-to-MACRO translator wouldn't be too
difficult to write, since GCC doesn't depend too heavily on GASsisms.
John Wilson
D Bit
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I would love to install that on PLUTO::.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Dave McGuire
Sent: Tue 1/15/2013 14:18
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] PDP-11 Algol
On 01/15/2013 11:58 AM, Paul_Koning at Dell.com wrote:
If I remember right, PDP-11 Algol has been mentioned on this list
from time to time. That was released via DECUS, and I've seen those
bits in the past. The problem always was that the runtime code
(algol.rts) showed up only as a binary, no sources.
It looks like I have a copy of the sources. Would there be interest
in that? This is for RSTS (as a runtime system) though the I/O is
pretty simple and could presumably be adjusted for some other OS if
anyone wants to.
I'd love to play with this!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Data General wrote their FORTRAN compilers in Algol (or was it Algol 68)... As a result their implementation had recursion. Few Fortran compiler had recursion. In college, the compiler class final was write an Algol compiler in the Fortran compiler. Weird... but fun!
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of hvlems at zonnet.nl
Sent: Tue 1/15/2013 12:15
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] PDP-11 Algol
There was a port of the Burroughs Large Systems algol compiler for RT11.
I have one on a DECtape I.
It compiled test programs that I had written for, and copied from the B7700. Burroughs Extended Algol beats C Bliss hands down as tool to write compilers and os's in.
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: [HECnet] PDP-11 Algol
Verzonden: 15 januari 2013 17:58
If I remember right, PDP-11 Algol has been mentioned on this list from time to time. That was released via DECUS, and I've seen those bits in the past. The problem always was that the runtime code (algol.rts) showed up only as a binary, no sources.
It looks like I have a copy of the sources. Would there be interest in that? This is for RSTS (as a runtime system) though the I/O is pretty simple and could presumably be adjusted for some other OS if anyone wants to.
By the way, I don't remember ever seeing a manual for the language implemented by that compiler. It turns out the best reference for that would be a manual for one of the Burroughs mainframes (say, the B5500 or B6700), which can be found on Bitsavers. The implementation actually compiles for P-code that resembles the machine code of those machines, except for using 16 bit words rather than 48/53 bit ones. The language has a number of large extensions that were taken directly from the I/O and string processing extensions in Burroughs Algol.
paul
GEM had nothing to do with PDP-11's. It started out life on VMS (without the "Open").
-Steve
PS: My wife was one of the Engineers on the GEM project.
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Clem Cole
Sent: Tue 1/15/2013 11:57
To: hecnet at update.uu.se
Subject: Re: [HECnet] Benchmarks - WHETSTONE.C
On Tue, Jan 15, 2013 at 11:50 AM, Johnny Billquist <bqt at softjar.se> wrote:
The PDP-11 C compiler is a much later product than any of the stuff you talk about here. It's something DEC did in the 90s.
Fair enough - long after I was paying much attention. Do you know if it was part of GEM? The GEM suite allowed N front ends, and Y back-ends.
As for PL/1 on 16 bit machines - it was done, particularly with subset compilers. Again, I lost interest in it in the early 1980s. PL/C was Cornell's version and a number of things like Intel's PL/M for the 8080 appeared, Stanfords PL/360 etc, all show it possible,
The question really was the desire and how far you wanted to go.
Clem
Is their a version of PCC that could generate PDP-11 assembly code?
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of John Wilson
Sent: Tue 1/15/2013 21:46
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Benchmarks - WHETSTONE.C
On Tue, Jan 15, 2013 at 05:56:33PM +0100, Johnny Billquist wrote:
That it would... Anyone have GCC setup to generate something that can
be linked under RSX?
That's a tall order (adding .OBJ to binutils?) ... and lately I think GCC for
PDP-11s is pretty badly broken. I built the (then-)latest GCC to cross-compile
for PDP-11s a few weeks ago (working on porting Conticki) and it's pretty
broken -- stack frames get all tangled up on any function with >2 locals.
Turning off frame pointers or enabling optimization just makes it worse.
I did a temporary hack which got it generating seemingly correct (but *awful*)
code, but I didn't understand how it worked well enough to really fix it. It
seems like it's trying to keep track of modifications to SP but apparently on
*any* modification it assumes that it's lost track of the top of the stack
(even if the modification was push and then pop, i.e. no net change) and tries
to dig its way out with the frame pointer (which it gets off by a word).
But anyway ... I would think a GAS-to-MACRO translator wouldn't be too
difficult to write, since GCC doesn't depend too heavily on GASsisms.
John Wilson
D Bit
On 15 Jan 2013, at 20:25, Jordi Guillaumes i Pons <jg at jordi.guillaumes.name> wrote:
El 15/01/2013, a les 20:27, Paul_Koning at Dell.com va escriure:
When I build it with the default build settings (async I/O enabled) both PDP11 and VAX hang at boot. Built with NOASYNCH and it runs fine. I haven't tried other platforms.
I have. Mark is working on the hang issues. He has fixed some of the bugs, but that asynch code seems to be specially hard to debug. BTW it is a multicore-multiprocessor issue also observed in other operating systems.
I'm curious if anyone else has tried it, or has ideas of what's wrong here. When it gets in this state, I have to kill the process; it won't answer interrupts or even SIGTERM.
I run it with asynch disabled for the time being.
When I try that, it fails to link.
Undefined symbols for architecture x86_64:
"_clock_gettime", referenced from:
_todr_wr in ccGqWyaE.o
_todr_resync in ccGqWyaE.o
_todr_rd in ccGqWyaE.o
ld: symbol(s) not found for architecture x86_64
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
The PDP-11 "C" compiler was a buyout. It started life out as a PASCAL compiler. The first project leader (J. Bishop) works for Intel - on the West Coast.
-Steve
________________________________
From: owner-hecnet at Update.UU.SE on behalf of Clem Cole
Sent: Tue 1/15/2013 16:27
To: Johnny Billquist
Cc: hecnet at update.uu.se
Subject: Re: [HECnet] Benchmarks - WHETSTONE.C
On Tue, Jan 15, 2013 at 3:55 PM, Johnny Billquist <bqt at softjar.se> wrote:
he DEC PDP-11 C runs on the PDP-11, it's not a cross compiler.
Interesting, I learned something here. As I said - by that time, I long lost interest in the 11.
I'll have to ask around up here in compiler land if anyone remembers anything about it and who led its development.
On Tue, 15 Jan 2013 16:53:50 -0500
Clem Cole <clemc at ccc.com> wrote:
[...snip...]
That said, by the time PL/1 came on the scene (late 1960s/early
1970s), it was pretty much de rigro that that a compiler was written
in it self to demonstrate the power of the language. And the boot
strap compiler was one a one shot thing and tossed aside as soon as a
working compiler staggered to its feet (think Ken Thompson's Turing
Award lecture on security). For instance BLISS was said to have been
boot strapped as a set of TECO macro's on the 10 - Eklund says he
According to Ron Brender the BLISS-10 compiler was originally
written in a BLISS pseudo-code which has then hand-translated into
assembly, which then bootstrapped the compiler.
I do know that TECO macros were initially used to pre-process
BLISS-10 structure definitions and expand them.
does not remember, but he did tell me once that it might have been so
when I asked him [While I was there, I was not part of that thread -
where as Dave was one of Wulf's grad students at CMU when Bill
designed and implemented BLISS -- Eklund is still hacking on the
Intel FTN Compiler a few days a week BTW].
The Multics, Prime et al PL/1 were written in PL/1 (by Frieberghouse)
- which is why Culter went there to get the front end when he created
his company. Again, I do not know how it was boot strapped. It's
possible PL/1 for Multics was bootstrapped from GECOS and in
something like BCPL - anyone know? Also, there were a number of
firms at the time in the Boston area doing compilers.
PL/I on Multics went through several iterations. Before full PL/I
there was EPL, a cut down PL/I that was missing a lot of I/O features.
