On Tue, 15 Jan 2013 12:06:29 -0500, you wrote:
SYS$STARTUP:SYLOGIN.COM? I thought it was in SYS$MANAGER?
If it's in the right place, both logicals will work :)
try sho log sys$startup and sho log sys$manager :)
G.
On Tue, Jan 15, 2013 at 12:05 PM, Johnny Billquist <bqt at softjar.se> wrote:
I don't think it was, but It's hard to say, as it's just one big binary blob to me. However, would the GEM even fit on a PDP-11?
It would not easily self host, but few of the PDP-11 compilers were asked to self host. They started cross compiling from the 10's then from the Vaxen. By the time PDP-11 went EOL, the cross compilers were running on Alpha (and maybe PMAX - again too man beers ago).
On Tue, 15 Jan 2013 11:57:45 -0500
Clem Cole <clemc at ccc.com> wrote:
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.
GEM never generated code for the PDP-11. It did do IA-32, IA-64, Alpha,
MIPS. I supports a range of operating systems including Windows,
OpenVMS, Tru64, Linux and NonStop (although that never made it to
production).
To get an idea, check out my BLISS family-tree at:
http://tim.sneddon.id.au/blog/Posts/A_BLISS-ful_family_tree
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,
PL/M was more of a language of it's own, based on PL/I. The others
I can't really speak for.
Regards, Tim.
On Jan 15, 2013, at 11:56 AM, Johnny Billquist wrote:
On 2013-01-15 17:00, Paul_Koning at Dell.com wrote:
...
It would be interesting to see how GCC does with whetstone.c.
That it would... Anyone have GCC setup to generate something that can be linked under RSX?
Right now GCC doesn't generate DEC-compatible assembly output. Its switches suggest that it does, but its "DEC" output style isn't. That is on my to be fixed list, behind a number of other things.
But it probably works well enough at the moment that one could run it, mung the generated assembly code a bit to convert from the default "gnu as" syntax to DEC syntax, and go from there.
paul
On 15 Jan 2013, at 12:13, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 1/15/2013 11:55 AM, Cory Smelosky wrote:
I will try that but I doubt it'll make any difference. The cisco autodetects 100/full on both of it's virtual interfaces. The AlphaVM-free link to the localhost loopback also comes up 10/half.
Is it actually throttling it to 10/half, or is that just a side effect of the card it emulates?
I'm honestly not sure, I've never used AlphaVM-free before.
What I do know if throughput is astoundingly bad and reliability doesn't seem to be real good, either.
Sure you don't want to play with an account on my Alpha? ;)
What's the host NIC?
-brian
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
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
On 1/15/2013 11:55 AM, Cory Smelosky wrote:
>I will try that but I doubt it'll make any difference. The cisco autodetects 100/full on both of it's virtual interfaces. The AlphaVM-free link to the localhost loopback also comes up 10/half.
Is it actually throttling it to 10/half, or is that just a side effect of the card it emulates?
I'm honestly not sure, I've never used AlphaVM-free before.
What I do know if throughput is astoundingly bad and reliability doesn't seem to be real good, either.
-brian
On Tue, 15 Jan 2013 17:56:46 +0100
G. <gerry77 at mail.com> wrote:
On Tue, 15 Jan 2013 11:46:34 -0500, you wrote:
How do I do multiple search paths?
-brian
On 1/15/2013 11:35 AM, hvlems at zonnet.nl wrote:
def/use dcl$path dka0::[bin]
Never tried, but I suppose that something like the following would
work:
$ DEFINE "DKA0:[first],DKA0:[second],DKA0:[third]"
You also need to drop the quotes, otherwise it won't be recognised as a
search list. So, more like:
$ DEFINE DCL$PATH DKA0:[first],DKA0:[second],DKA0:[third]
Regards, Tim.
On 15 Jan 2013, at 12:03, Brian Hechinger <wonko at 4amlunch.net> wrote:
On 1/15/2013 11:56 AM, G. wrote:
On Tue, 15 Jan 2013 11:46:34 -0500, you wrote:
How do I do multiple search paths?
-brian
On 1/15/2013 11:35 AM, hvlems at zonnet.nl wrote:
def/use dcl$path dka0::[bin]
Never tried, but I suppose that something like the following would work:
$ DEFINE "DKA0:[first],DKA0:[second],DKA0:[third]"
Please note that if you define your logical as /USER it will disappear as soon
as you return to DCL after running whatsoever .EXE program!
That explains that then. :)
So, I've got vim installed and working, however I'm having some trouble getting this to work they way I think it should.
I'm following the directions at:
http://www.polarhome.com/vim/manual/v73/os_vms.html
I've done this:
System administrators might want to set up a system wide Vim installation,
then add to the SYS$STARTUP:SYLOGICALS.COM
$ define/nolog/sys VIM device:<path>
$ define/nolog/sys TMP SYS$SCRATCH
And to the SYS$STARTUP:SYLOGIN.COM
SYS$STARTUP:SYLOGIN.COM? I thought it was in SYS$MANAGER?
$ vi*m :== mcr VIM:VIM.EXE
$ gv*im:== spawn/nowait/input=NLA0 mcr VIM:VIM.EXE -g -GEOMETRY 80x40
But it isn't working.
$ vim
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\VIM\
$ vi
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\VI\
$
Any ideas?
-brian
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On 2013-01-15 17:57, Clem Cole wrote:
On Tue, Jan 15, 2013 at 11:50 AM, Johnny Billquist <bqt at softjar.se
<mailto: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.
I don't think it was, but It's hard to say, as it's just one big binary blob to me. However, would the GEM even fit on a PDP-11?
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.
Right. I'm sure that with enough work, you can always do it, but I'm curious on how much work. I have a feeling that compilers written in high level languages rapidly expand their requirements...
Johnny
