On Jan 16, 2013, at 5:21 PM, <Paul_Koning at Dell.com>
wrote:
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
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
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
I should have just looked it up first rather than answering from memory. Here is the fix:
diff --git a/sim_timer.c b/sim_timer.c
index 6044643..8c1e9e7 100644
--- a/sim_timer.c
+++ b/sim_timer.c
@@ -402,7 +402,7 @@ if (tim > SIM_IDLE_MAX)
tim = 0;
return tim;
}
-#if !defined(_POSIX_SOURCE) && defined(SIM_ASYNCH_IO)
+#if !defined(_POSIX_SOURCE)
#ifdef NEED_CLOCK_GETTIME
typedef int clockid_t;
int clock_gettime(clockid_t clk_id, struct timespec *tp)
paul
On Jan 16, 2013, at 3:17 PM, Cory Smelosky wrote:
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
I noticed that one. Find clock_gettime. It's currently conditional on two things one of which is async support. Take away that second check.
paul
Hello!
I'm going to be moving some of my equipment to the basement here for several reasons (heat produced, noise, space, et cetera), and in planning i'm hitting a roadblock: networking.
I've come up with several ideas:
Wireless client-bridge: Linksys e1000 is garbage and doesn't like to pass DECnet or any of those protocols, so i'd either need a workaround or a better router. (workaround being: a virtual cisco tunnel to my other virtual cisco?) (Other router: /real/ Cisco or a another suggestion from someone on this list)
Powerline ethernet: Is this reliable yet? How are the transfer speeds?
Or: Adding a phone jack, getting DSL on the second line here. (installation costs, but would actually be $2 more/month to upgrade current plan + add a second identical plan not counting hardware rental fees, setup costs, and that stuff)
Running cables all the way from the second floor isn't viable.
Any (viable) options i'm missing?
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
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
