Looking for Johnson's pcc - DG Nova and Eclipse
toby
In their paper, "Portability of C Programs and the UNIX System", S.C.
Johnson and Dennis Ritchie write,
\\
Even before the idea of moving UNIX occurred to us, it was clear that C
was successful enough to warrant production of compilers for an
increasing variety of machines. Therefore, one of the authors (SCJ)
undertook to produce a new compiler intended from the start to be
easily modified. This new compiler is now in use on the IBM System/370
under both OS and TSS, the Honeywell 6000, the
Interdata 8/32, the SEL86 the Data General Nova and Eclipse, the DEC
VAX11/780, and a Bell System processor. Versions are in progress for
the Intel 8086 microprocessor and other machines.
//
Do any of these ports of pcc or pcc2 still exist? I am interested in
the Nova/Eclipse versions in particular.
--Toby
Dennis Ritchie
"toby" <to...@telegraphics.com.au> wrote in message news:1145627720....@v46g2000cwv.googlegroups.com...
Toby asked about versions of Johnson's pcc, in particular
>
> Do any of these ports of pcc or pcc2 still exist? I am interested in
> the Nova/Eclipse versions in particular.
>
> --Toby
I'm not aware of extant versions of Nova/Eclipse versions of this.
pcc versions for the PDP11 were in Seventh Ed. and for the VAX
in 32V as well as the earlier BSD distributions (these are definitely
available at tuhs.org). The other instances would be harder to find.
Early Sun systems used it for the Moto 68K, for example.
Dennis
ArarghMai...@not.at.arargh.com
I would be interested in the Nova version, if a copy ever surfaces.
16-bit word machine, 4 regs, no stack. . . The Eclipse was a somewhat
different critter, and I never saw one.
Might be fun to try to port 6th or 7th Edition to a Nova. :-) It
would give me a reason to get the Nova clones I have working again.
--
ArarghMail604 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
William J. Leary Jr.
news:elbj42t9fica9og6s...@4ax.com...
> On Sat, 22 Apr 2006 03:50:09 -0000, "Dennis Ritchie"
> 16-bit word machine, 4 regs, no stack. . .
Later versions had both a stack and a frame pointer (thought I expect you knew
that).
Didn't help me any, though, since my code had to run on the entire product line
I couldn't use them.
- Bill
toby
> On Sat, 22 Apr 2006 03:50:09 -0000, "Dennis Ritchie"
> <d...@bell-labs.com> wrote:
>
> >
> >"toby" <to...@telegraphics.com.au> wrote in message news:1145627720....@v46g2000cwv.googlegroups.com...
> >
> >Toby asked about versions of Johnson's pcc, in particular
> >>
> >> Do any of these ports of pcc or pcc2 still exist? I am interested in
> >> the Nova/Eclipse versions in particular.
> >>
> >> --Toby
> >
> >I'm not aware of extant versions of Nova/Eclipse versions of this.
> >pcc versions for the PDP11 were in Seventh Ed. and for the VAX
> >in 32V as well as the earlier BSD distributions (these are definitely
> >available at tuhs.org). The other instances would be harder to find.
> >Early Sun systems used it for the Moto 68K, for example.
> >
> I would be interested in the Nova version, if a copy ever surfaces.
> 16-bit word machine, 4 regs, no stack. . . The Eclipse was a somewhat
> different critter, and I never saw one.
>
> Might be fun to try to port 6th or 7th Edition to a Nova. :-)
Yes, it would... If only it were still around, this compiler would be a
nice start. iirc Johnson's "pcc2" was an improved version that made
retargetability easier (I can't exactly recall where I read this).
Perhaps, starting from pcc2, it would be possible to simply redo
creating the Nova/Eclipse target. (Although the original work probably
required many changes to the compiler itself beyond the machine
description, since target parameters would not likely have included
support for 2 pointer types, etc.)
Was the original pcc/DG port part of a UNIX port? Or was it intended to
run under RDOS or similar? Chris Torek's past posts often refer to C on
Nova/Eclipse, but I suspect he wasn't talking about pcc itself.
--Toby
ArarghMai...@not.at.arargh.com
<Bill_...@msn.com> wrote:
><ArarghMai...@NOT.AT.Arargh.com> wrote in message
>news:elbj42t9fica9og6s...@4ax.com...
>> I would be interested in the Nova version, if a copy ever surfaces.
>> 16-bit word machine, 4 regs, no stack. . .
>
>Later versions had both a stack and a frame pointer (thought I expect you knew
>that).
I thought only Eclipses' had those. But, I really don't know as I
never used any Nova, except for my DCC-116s. I think that they are
Nova 2 clones, but a bit faster.
>Didn't help me any, though, since my code had to run on the entire product line
>I couldn't use them.
William J. Leary Jr.
news:mi2l429q3kjd4v95m...@4ax.com...
> On Sat, 22 Apr 2006 02:17:07 -0400, "William J. Leary Jr."
> <Bill_...@msn.com> wrote:
> ><ArarghMai...@NOT.AT.Arargh.com> wrote in message
> >news:elbj42t9fica9og6s...@4ax.com...
> >> I would be interested in the Nova version, if a copy ever surfaces.
> >> 16-bit word machine, 4 regs, no stack. . .
> >
> >Later versions had both a stack and a frame pointer (thought I expect you
knew
> >that).
>
> I thought only Eclipses' had those.
Nova 3 added a stack and fram pointer. It's arguable that the Nova 3 wanted to
be an Eclipse. It could at least be viewed as a stepping stone in that
direction.
> But, I really don't know as I
> never used any Nova, except for my DCC-116s. I think that they are
> Nova 2 clones, but a bit faster.
The DCC-116 was a Nova 2 clone, as I recall. The 216, 316, etc. were faster
versions of the same archetecture.
- Bill
ArarghMai...@not.at.arargh.com
wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>> On Sat, 22 Apr 2006 03:50:09 -0000, "Dennis Ritchie"
>> <d...@bell-labs.com> wrote:
>> >"toby" <to...@telegraphics.com.au> wrote in message news:1145627720....@v46g2000cwv.googlegroups.com...
>> >Toby asked about versions of Johnson's pcc, in particular
>> >> Do any of these ports of pcc or pcc2 still exist? I am interested in
>> >> the Nova/Eclipse versions in particular.
>> >I'm not aware of extant versions of Nova/Eclipse versions of this.
>> >pcc versions for the PDP11 were in Seventh Ed. and for the VAX
>> >in 32V as well as the earlier BSD distributions (these are definitely
>> >available at tuhs.org). The other instances would be harder to find.
>> >Early Sun systems used it for the Moto 68K, for example.
>> >
>> I would be interested in the Nova version, if a copy ever surfaces.
>> 16-bit word machine, 4 regs, no stack. . . The Eclipse was a somewhat
>> different critter, and I never saw one.
>>
>> Might be fun to try to port 6th or 7th Edition to a Nova. :-)
>
>Yes, it would... If only it were still around, this compiler would be a
>nice start. iirc Johnson's "pcc2" was an improved version that made
>retargetability easier (I can't exactly recall where I read this).
>Perhaps, starting from pcc2, it would be possible to simply redo
>creating the Nova/Eclipse target. (Although the original work probably
>required many changes to the compiler itself beyond the machine
>description, since target parameters would not likely have included
>support for 2 pointer types, etc.)
Well, I have the pcc source from 7th Ed., and if I got interested
enough, I could always tackle porting it to the Nova. I wonder if I
could use the auto-increment/auto-decrement low core locations as a
fake stack pointer? I would also have to use R2 as a frame pointer.
>Was the original pcc/DG port part of a UNIX port?
I have no idea.
>Or was it intended to
>run under RDOS or similar? Chris Torek's past posts often refer to C on
>Nova/Eclipse, but I suspect he wasn't talking about pcc itself.
ArarghMai...@not.at.arargh.com
<Bill_...@msn.com> wrote:
><ArarghMai...@NOT.AT.Arargh.com> wrote in message
>news:mi2l429q3kjd4v95m...@4ax.com...
<snip>
>> I thought only Eclipses' had those.
>
>Nova 3 added a stack and fram pointer. It's arguable that the Nova 3 wanted to
>be an Eclipse. It could at least be viewed as a stepping stone in that
>direction.
Ok. Never used a Nova 3.
>> But, I really don't know as I
>> never used any Nova, except for my DCC-116s. I think that they are
>> Nova 2 clones, but a bit faster.
>
>The DCC-116 was a Nova 2 clone, as I recall. The 216, 316, etc. were faster
>versions of the same archetecture.
Nova 1200 clone, according to the URL below.
I have 4 DCC D-116 Es, and I once saw a DCC-616. A FPOE had one in
for an eval. 1975 maybe? I think that DCC folded (or rather got
folded) about then. I don't know if the 616 ever made it into
production. I doubt it.
Something of a DCC mini history:
http://www.simulogics.com/nostalgia/DCC/dcc.htm
William J. Leary Jr.
news:rh4l42llni2dnv6ds...@4ax.com...
> On Sat, 22 Apr 2006 16:29:05 -0400, "William J. Leary Jr."
> <Bill_...@msn.com> wrote:
> >The DCC-116 was a Nova 2 clone, as I recall. The 216, 316, etc. were faster
> >versions of the same archetecture.
> Nova 1200 clone, according to the URL below.
Right... typo.
The Nova 1200 was so-named because that was it's cycle time. If you happen to
know the DCC-116's cycle time, that'll tell if it was faster or not.
> I have 4 DCC D-116 Es, and I once saw a DCC-616. A FPOE had one in
> for an eval. 1975 maybe? I think that DCC folded (or rather got
> folded) about then. I don't know if the 616 ever made it into
> production. I doubt it.
I used a couple of DCC's, running RDOS. I *think* the 116 version, but I can't
say from this point in time.
As I recalled, we got them through some deal with DG after DG sued DCC out of
business and absorbed their stock. If I'm remembering the deal, we were
allowed to use them for internal operations (test beds and so forth), but
couldn't include them in our OEM product (which was built around Nova 1200's,
800's, and 3's).
> Something of a DCC mini history:
> http://www.simulogics.com/nostalgia/DCC/dcc.htm
Ah, yes. There's part of that story there.
- Bill
ArarghMai...@not.at.arargh.com
<Bill_...@msn.com> wrote:
><ArarghMai...@NOT.AT.Arargh.com> wrote in message
>news:rh4l42llni2dnv6ds...@4ax.com...
>> On Sat, 22 Apr 2006 16:29:05 -0400, "William J. Leary Jr."
>> <Bill_...@msn.com> wrote:
>> >The DCC-116 was a Nova 2 clone, as I recall. The 216, 316, etc. were faster
>> >versions of the same archetecture.
>> Nova 1200 clone, according to the URL below.
>
>Right... typo.
>
>The Nova 1200 was so-named because that was it's cycle time. If you happen to
>know the DCC-116's cycle time, that'll tell if it was faster or not.
980ns is the number I remember. IIRC, the ones I have are D-116EH's
(extended chassis & faster clock). The DCC quick reference has no
timings, and the Nixdorf version of the card has two different times,
800 & 1200. I guess I would have to check the prints & crystals to
find out just how fast the ones I have really are.
>> I have 4 DCC D-116 Es, and I once saw a DCC-616. A FPOE had one in
>> for an eval. 1975 maybe? I think that DCC folded (or rather got
>> folded) about then. I don't know if the 616 ever made it into
>> production. I doubt it.
>
>I used a couple of DCC's, running RDOS. I *think* the 116 version, but I can't
>say from this point in time.
>
>As I recalled, we got them through some deal with DG after DG sued DCC out of
>business and absorbed their stock. If I'm remembering the deal, we were
>allowed to use them for internal operations (test beds and so forth), but
>couldn't include them in our OEM product (which was built around Nova 1200's,
>800's, and 3's).
I don't know where Nixdorf got them, but they were selling DCC's into
the early 80's as the processor in the 8870 system. Later, they
started building processors in Germany, which weren't all that
compatible, especially in the I/O department.
<snip>
toby
Is that pcc1 or pcc2 (I'm going from vague memory here from some
reading a year or so ago, that pcc went through an improved rewrite)?
> I wonder if I
> could use the auto-increment/auto-decrement low core locations as a
> fake stack pointer? I would also have to use R2 as a frame pointer.
I put quite a bit of thought into targeting lcc[1] to Nova, but this
foundered mainly on these points:
* an essential presumption of byte addressing means modifying lcc
itself to deal with the concept of 2 pointer classes;
* lcc much prefers many more registers (even the PDP-11[2] strains this
to the limit);
* supporting long types is not particularly elegant in lcc 16-bit
machine descriptions.
Nonetheless, Nova is such a fun architecture that the challenge of a
producing a good C for it isn't easily ignored. Simh makes a good
environment for testing under RDOS, and is probably good enough to test
a UNIX port in, also :)
[1] http://www.cs.princeton.edu/software/lcc/
[2] http://telegraphics.com.au/sw/info/lcc-pdp11.html
ArarghMai...@not.at.arargh.com
>ArarghMai...@NOT.AT.Arargh.com wrote:
>> Well, I have the pcc source from 7th Ed., and if I got interested
>> enough, I could always tackle porting it to the Nova.
>
>Is that pcc1 or pcc2 (I'm going from vague memory here from some
>reading a year or so ago, that pcc went through an improved rewrite)?
>> I wonder if I
>> could use the auto-increment/auto-decrement low core locations as a
>> fake stack pointer? I would also have to use R2 as a frame pointer.
>
>I put quite a bit of thought into targeting lcc[1] to Nova, but this
>foundered mainly on these points:
>* an essential presumption of byte addressing means modifying lcc
>itself to deal with the concept of 2 pointer classes;
That problem would exist for any word addressed system.
>* lcc much prefers many more registers (even the PDP-11[2] strains this
>to the limit);
I would be more inclined to start with something like the 'Small-C'
compiler, and work up.
this one:
Small-C Compiler
Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>* supporting long types is not particularly elegant in lcc 16-bit
>machine descriptions.
All I would tackle is char, int, long (8,16,32) -- and maybe skip long
>
>Nonetheless, Nova is such a fun architecture that the challenge of a
>producing a good C for it isn't easily ignored. Simh makes a good
>environment for testing under RDOS, and is probably good enough to test
>a UNIX port in, also :)
>
>[1] http://www.cs.princeton.edu/software/lcc/
>[2] http://telegraphics.com.au/sw/info/lcc-pdp11.html
>
<snip>
toby
> On 22 Apr 2006 23:07:33 -0700, "toby" <to...@telegraphics.com.au>
> >ArarghMai...@NOT.AT.Arargh.com wrote:
> >> Well, I have the pcc source from 7th Ed., and if I got interested
> >> enough, I could always tackle porting it to the Nova.
> >
> >Is that pcc1 or pcc2 (I'm going from vague memory here from some
> >reading a year or so ago, that pcc went through an improved rewrite)?
> I have no idea.
>
> >> I wonder if I
> >> could use the auto-increment/auto-decrement low core locations as a
> >> fake stack pointer? I would also have to use R2 as a frame pointer.
> >
> >I put quite a bit of thought into targeting lcc[1] to Nova, but this
> >foundered mainly on these points:
> >* an essential presumption of byte addressing means modifying lcc
> >itself to deal with the concept of 2 pointer classes;
> That problem would exist for any word addressed system.
Indeed. I expect pcc made the same presumption.
>
> >* lcc much prefers many more registers (even the PDP-11[2] strains this
> >to the limit);
> I would be more inclined to start with something like the 'Small-C'
> compiler, and work up.
>
> this one:
> Small-C Compiler
> Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>
>
> >* supporting long types is not particularly elegant in lcc 16-bit
> >machine descriptions.
> All I would tackle is char, int, long (8,16,32) -- and maybe skip long
I was referring to long = 32. In an lcc machine description this gets
ugly for PDP-11; another of its presumptions is that you'll have
registers of your operand width (which for longs is true on any 32 bit
system of course). Just another indication that while it's possible to
go there, 16 bitters are outside lcc's sweet spot. I agree other
compilers are probably easier starting points (I wonder about tcc[3]?).
lcc's advantage, apart from anything else, is it is correct and
complete ANSI.
[3] http://fabrice.bellard.free.fr/tcc/
> ...
ArarghMai...@not.at.arargh.com
wrote:
tcc looks a little too 32BITish and a little too X86ish for my taste,
after a very quick look.
The reason I would start with a Small-C Compiler is that it is already
a 16 BITter, and the fact that I have the source and a working
version.
Actually I seem to have several versions of 'Small-C' compilers. The
one I mentioned above is not the one that I was thinking of when I
wrote the following paragraph. The version I was thinking of is:
"small-c:PC compiler by Ron Cain"
It's main problem is that it generates fairly ugly code, at least the
x86 version does. I could probably hack a version of this in a week
or two, and get it to output Nova assembler code. Maybe I will, just
for something to do.
Hmmm, size may be an issue. The MS/PC DOS exe is 40k bytes - that's
over half of the Nova's memory. :-)
Another issue, do I write it for the only Nova OS that I have (IRIS
from EDS, later Point4) or standalone?
Also, write for a stock Nova, or the modified clone processors that I
have. The ones I have support 64k words of core, but you lose the
LDA/STA memory indirect chaining feature. But they will run as stock.
toby
> On 23 Apr 2006 10:45:08 -0700, "toby" <to...@telegraphics.com.au>
> wrote:
> >compilers are probably easier starting points (I wonder about tcc[3]?).
> >lcc's advantage, apart from anything else, is it is correct and
> >complete ANSI.
> >
> >[3] http://fabrice.bellard.free.fr/tcc/
> >
> tcc looks a little too 32BITish and a little too X86ish for my taste,
> after a very quick look.
>
> The reason I would start with a Small-C Compiler is that it is already
> a 16 BITter, and the fact that I have the source and a working
> version.
>
> Actually I seem to have several versions of 'Small-C' compilers. The
> one I mentioned above is not the one that I was thinking of when I
> wrote the following paragraph. The version I was thinking of is:
> "small-c:PC compiler by Ron Cain"
>
> It's main problem is that it generates fairly ugly code, at least the
> x86 version does. I could probably hack a version of this in a week
> or two, and get it to output Nova assembler code. Maybe I will, just
> for something to do.
You can use my cross-assembler[4] for the next stage :-) It generates
RDOS relocatable object (RB). Do you have reference manuals for the
assembler syntax? I can certainly provide them.
>
> Hmmm, size may be an issue. The MS/PC DOS exe is 40k bytes - that's
> over half of the Nova's memory. :-)
Cross-compilation/cross-assembly is fine for my purposes.
>
> Another issue, do I write it for the only Nova OS that I have (IRIS
> from EDS, later Point4) or standalone?
Ooh! Please tell me more about that O/S. What are the chances of
getting a disk image to run under Simh? Do you have documentation? The
only Nova O/S that I have seen is RDOS (an image ships with Simh).
>
> Also, write for a stock Nova, or the modified clone processors that I
> have. The ones I have support 64k words of core, but you lose the
> LDA/STA memory indirect chaining feature. But they will run as stock.
My main interest is Nova3 (I have a friend with two of them).
[4] http://www.telegraphics.com.au/sw/#dpa
Peter Flass
>
> Actually I seem to have several versions of 'Small-C' compilers. The
> one I mentioned above is not the one that I was thinking of when I
> wrote the following paragraph. The version I was thinking of is:
> "small-c:PC compiler by Ron Cain"
>
> It's main problem is that it generates fairly ugly code, at least the
> x86 version does. I could probably hack a version of this in a week
> or two, and get it to output Nova assembler code. Maybe I will, just
> for something to do.
It couldn't do much else, given the hardware it was originally targeted
to run on. Also, perhaps it would do better on a less CISC machine than
the x86.
...
>
> Another issue, do I write it for the only Nova OS that I have (IRIS
> from EDS, later Point4) or standalone?
Is it possible to generate code that will run either way, and have the
OS-dependent (or standalone-dependent) stuff in the RTL?
ArarghMai...@not.at.arargh.com
>You can use my cross-assembler[4] for the next stage :-) It generates
>RDOS relocatable object (RB). Do you have reference manuals for the
>assembler syntax? I can certainly provide them.
>> Hmmm, size may be an issue. The MS/PC DOS exe is 40k bytes - that's
>> over half of the Nova's memory. :-)
>
>Cross-compilation/cross-assembly is fine for my purposes.
If I ever get that far.
>> Another issue, do I write it for the only Nova OS that I have (IRIS
>> from EDS, later Point4) or standalone?
>
>Ooh! Please tell me more about that O/S.
Besides that it's long dead :-)
Multi user time sharing system. Apps programmed in interpreted basic.
System written in assembler.
>What are the chances of
>getting a disk image to run under Simh?
Slim, for several reasons. It is still under copyright, and has never
been released, AFAIK. Also, in order for it to run, there is a
license device, called a 'PICO', that has to be fastened to the
backplane. And they are version specific. The same kind of thing as
used on the parallel port for software protection for PC's.
Another issue is that all the copies that I have are setup for either
Diablo 44 Drives, on the DCC controller (Device ID 33) or Point 4 SMD
controller (Device ID 27). I doubt that Simh knows about those
controllers.
>Do you have documentation?
Of course.
>The only Nova O/S that I have seen is RDOS (an image ships with Simh).
ISTR that DG made RDOS avail for personal use. I don't know that to
be true for IRIS. That doesn't matter for me, as I have the licenses,
but it does for allowing anyone else to have a copy. I have
corresponded with someone who was trying to get IRIS released. I will
contact him again to see if he has made any progress. It has been a
few years.
>> Also, write for a stock Nova, or the modified clone processors that I
>> have. The ones I have support 64k words of core, but you lose the
>> LDA/STA memory indirect chaining feature. But they will run as stock.
>
>My main interest is Nova3 (I have a friend with two of them).
Well, since the Nova 3 has a stack, life would be much easier for a C
compiler. But, I don't have a Nova 3. I knew someone that had one, I
wonder if he still does. Maybe he would give it to me, if he no
longer wants it. Have to check.
CBFalconer
>> ArarghMai...@NOT.AT.Arargh.com wrote:
>>
... snip ...
>>>
>>> this one:
>>> Small-C Compiler
>>> Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>>>
>
> Actually I seem to have several versions of 'Small-C' compilers.
> The one I mentioned above is not the one that I was thinking of
> when I wrote the following paragraph. The version I was thinking
> of is: "small-c:PC compiler by Ron Cain"
Ron Cain was the originator, who then retired from the field. I
always felt that the seizure by Hendrix was not right, although he
did make improvements.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
ArarghMai...@not.at.arargh.com
wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>>> ArarghMai...@NOT.AT.Arargh.com wrote:
>>>
>... snip ...
>>>>
>>>> this one:
>>>> Small-C Compiler
>>>> Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>>>>
>... snip ...
>>
>> Actually I seem to have several versions of 'Small-C' compilers.
>> The one I mentioned above is not the one that I was thinking of
>> when I wrote the following paragraph. The version I was thinking
>> of is: "small-c:PC compiler by Ron Cain"
>
>Ron Cain was the originator, who then retired from the field.
Any idea why?
>I always felt that the seizure by Hendrix was not right, although he
>did make improvements.
The only noticeable improvement that I remember is a peep-hole
optimizer of sorts, in version 2.2. There may have been others.
I played around mostly with the 1.1 version: "small-c:PC compiler by
Ron Cain", and am most familiar with it.
ArarghMai...@not.at.arargh.com
wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>>
>> Actually I seem to have several versions of 'Small-C' compilers. The
>> one I mentioned above is not the one that I was thinking of when I
>> wrote the following paragraph. The version I was thinking of is:
>> "small-c:PC compiler by Ron Cain"
>>
>> It's main problem is that it generates fairly ugly code, at least the
>> x86 version does. I could probably hack a version of this in a week
>> or two, and get it to output Nova assembler code. Maybe I will, just
>> for something to do.
>
>It couldn't do much else, given the hardware it was originally targeted
>to run on. Also, perhaps it would do better on a less CISC machine than
>the x86.
Maybe.
>...
>>
>> Another issue, do I write it for the only Nova OS that I have (IRIS
>> from EDS, later Point4) or standalone?
>
>Is it possible to generate code that will run either way, and have the
>OS-dependent (or standalone-dependent) stuff in the RTL?
I suppose. IRIS didn't have any notion of a loader or linker,
relocatable or otherwise. Programs were assembled at absolute load
locations, and used hard coded entries to "REX", (the kernel) for
various subroutine things, like keyboard input & output. Also, this
was a time sharing system, and programs had to check the time slice
counter, and swap themselves out, at the end of a time slice. (I don't
remember the details, just now. It's only been 20 years since I last
used this)
For example, IIRC, the command to write a string to the terminal was
"OUTTEXT", which was actually a "JSR @134" instruction. Loc 134 held
the address of the terminal output routine.
Since the various small-c compilers all output asm source, by not
specifying any location info it should be possible to do both. Then
for IRIS you could do something like:
asm cstart cbody clib
where cbody came from the c compiler. cstart would be the IRIS based
startup code, and clib would be all of the c library routines.
If I remember the assembler command correctly. :-)
toby
If you want any help, I'm happy to join forces. I can offer a colocated
Subversion repository for collaboration. Also another pair of coding
hands that likes compilers and knows Nova 3 reasonably well ;-) I also
have some rough notes[5] that I made when I was looking at lcc.
--Toby
[5] http://www.telegraphics.com.au/svn/dpa/trunk/nova/arch_notes.txt
(some of this may be out of date, incorrect or just plain silly. But
it's version controlled so you can check it out and commit any
corrections if I give you a login. Same goes for the rest of the
assembler project of which it is a part).
ArarghMai...@not.at.arargh.com
>ArarghMai...@NOT.AT.Arargh.com wrote:
<snip>
>> Actually I seem to have several versions of 'Small-C' compilers. The
>> one I mentioned above is not the one that I was thinking of when I
>> wrote the following paragraph. The version I was thinking of is:
>> "small-c:PC compiler by Ron Cain"
>>
>> It's main problem is that it generates fairly ugly code, at least the
>> x86 version does. I could probably hack a version of this in a week
>> or two, and get it to output Nova assembler code. Maybe I will, just
>> for something to do.
>
>If you want any help, I'm happy to join forces.
feasible such a hack would be.
The "small-c:PC compiler by Ron Cain" is version 1.1, and I have no
idea where I originally got it. Probably off some BBS. The original
files are dated 1985. I am more familiar with this version as I
converted it from C to Basic at some point.
The later version is still available online, and it would be a better
place to start. This copy matches the ones that I have on file:
http://www.programmersheaven.com/zone22/cat207/16184.htm
I will look at this versions code generating routines.
>I can offer a colocated Subversion repository for collaboration.
The compiler is only 4 small source files. :-)
>Also another pair of coding
>hands that likes compilers and knows Nova 3 reasonably well ;-) I also
>have some rough notes[5] that I made when I was looking at lcc.
>[5] http://www.telegraphics.com.au/svn/dpa/trunk/nova/arch_notes.txt
>(some of this may be out of date, incorrect or just plain silly. But
>it's version controlled so you can check it out and commit any
>corrections if I give you a login. Same goes for the rest of the
>assembler project of which it is a part).
Most of it looks reasonable, except I have no idea about the lcc
parts.
The stack instructions only apply to the Nova 3 & later -- none of my
hardware has it. The FP instructions were always optional, and, of
course, I don't have them either.
IRIS used decimal floating point subroutines in 3 sizes with 6 to 14
decimal digits of accuracy.
Hmm, maybe I should grab that routine and add it to my basic compiler.
toby
I find version control indispensable even as a lone developer working
on a single source file. But collaboration would be impossible without
Subversion - now that I am accustomed to its advantages :)
> ...
ArarghMai...@not.at.arargh.com
>ArarghMai...@NOT.AT.Arargh.com wrote:
<snip>
>>
>> >I can offer a colocated Subversion repository for collaboration.
>> The compiler is only 4 small source files. :-)
>
>I find version control indispensable even as a lone developer working
>on a single source file. But collaboration would be impossible without
>Subversion - now that I am accustomed to its advantages :)
>
of the two programs I most often use for source file editing know
anything about source control systems, being old DOS programs.
If my editors would automaticly grab their input from source control
and then save it back, I would be using it.
I have tried to use source control in the past, but I tend to get
involved in the project, and forget to use it.
Some time back, I was thinking that it would be nice if I knew of a
filesystem that did automatic source control, either FreeBSD or Win32
based. Then I could just store all the source on it, and access it as
if it were just a directory structure.
You don't happen to know of such a critter, do you?
toby
> On 24 Apr 2006 09:42:09 -0700, "toby" <to...@telegraphics.com.au>
> >ArarghMai...@NOT.AT.Arargh.com wrote:
> <snip>
> >>
> >> >I can offer a colocated Subversion repository for collaboration.
> >> The compiler is only 4 small source files. :-)
> >
> >I find version control indispensable even as a lone developer working
> >on a single source file. But collaboration would be impossible without
> >Subversion - now that I am accustomed to its advantages :)
> >
> Yes, I think that it would be useful for me, also. However, neither
> of the two programs I most often use for source file editing know
> anything about source control systems, being old DOS programs.
>
> If my editors would automaticly grab their input from source control
> and then save it back, I would be using it.
There is no need for editor integration. I've often used Subversion
from CLI but an IDE on top (for instance Microchip). Simply check out a
working copy and use whatever IDE/editor you like in it. This is quite
convenient, because commits are typically separated by bouts of
editing, building and testing (I make a rule of thumb to not commit
anything that doesn't build).
>
> I have tried to use source control in the past, but I tend to get
> involved in the project, and forget to use it.
Well, Subversion's simplicity and convenience might help. It is a
matter of habit, for sure.
Let's give this project a name, I'll create a repo and you can check in
the initial source (license permitting, we can have a public or private
repo).
>
> Some time back, I was thinking that it would be nice if I knew of a
> filesystem that did automatic source control, either FreeBSD or Win32
> based. Then I could just store all the source on it, and access it as
> if it were just a directory structure.
>
> You don't happen to know of such a critter, do you?
I have seen similar things. In fact you can use Subversion itself in
this way via a WebDAV mount. But for things like documentation TWiki is
a user friendly versioned system.
ArarghMai...@not.at.arargh.com
wrote:
>ArarghMai...@NOT.AT.Arargh.com wrote:
>> On 24 Apr 2006 09:42:09 -0700, "toby" <to...@telegraphics.com.au>
>> >ArarghMai...@NOT.AT.Arargh.com wrote:
>> <snip>
>> >>
>> >> >I can offer a colocated Subversion repository for collaboration.
>> >> The compiler is only 4 small source files. :-)
>> >
>> >I find version control indispensable even as a lone developer working
>> >on a single source file. But collaboration would be impossible without
>> >Subversion - now that I am accustomed to its advantages :)
>> >
>> Yes, I think that it would be useful for me, also. However, neither
>> of the two programs I most often use for source file editing know
>> anything about source control systems, being old DOS programs.
>>
>> If my editors would automaticly grab their input from source control
>> and then save it back, I would be using it.
>
>There is no need for editor integration. I've often used Subversion
>from CLI but an IDE on top (for instance Microchip).
>Simply check out a working copy and use whatever IDE/editor you like in it.
That's the part I tend to forget until it's too late. :-)
>This is quite
>convenient, because commits are typically separated by bouts of
>editing, building and testing (I make a rule of thumb to not commit
>anything that doesn't build).
>> I have tried to use source control in the past, but I tend to get
>> involved in the project, and forget to use it.
>
>Well, Subversion's simplicity and convenience might help. It is a
>matter of habit, for sure.
>
>Let's give this project a name, I'll create a repo and you can check in
>the initial source (license permitting, we can have a public or private
>repo).
cc1.c thru cc4.c from smallc22.zip from:
http://www.programmersheaven.com/zone22/cat207/16184.htm
Most of the code generation appears to be in cc4.
I need to dig thru and see if the optimizer is at the p-code level or
somewhere else. The 1.1 version used less registers, IIRC, and would
have been easier to modify. But, it supports much less of C features.
>> Some time back, I was thinking that it would be nice if I knew of a
>> filesystem that did automatic source control, either FreeBSD or Win32
>> based. Then I could just store all the source on it, and access it as
>> if it were just a directory structure.
>>
>> You don't happen to know of such a critter, do you?
>
>I have seen similar things. In fact you can use Subversion itself in
>this way via a WebDAV mount. But for things like documentation TWiki is
>a user friendly versioned system.
Oh, well.
Peter Flass
> ArarghMai...@NOT.AT.Arargh.com wrote:
>
>>>ArarghMai...@NOT.AT.Arargh.com wrote:
>>>
>
> ... snip ...
>
>>>>this one:
>>>>Small-C Compiler
>>>>Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>>>>
>
> ... snip ...
>
>>Actually I seem to have several versions of 'Small-C' compilers.
>>The one I mentioned above is not the one that I was thinking of
>>when I wrote the following paragraph. The version I was thinking
>>of is: "small-c:PC compiler by Ron Cain"
>
>
> Ron Cain was the originator, who then retired from the field. I
> always felt that the seizure by Hendrix was not right, although he
> did make improvements.
>
I remember that Doctor Dobbs Journal published the source (1.1?) in, I
believe, three parts, for the user to key in themselves. I think I kept
these issues somewhere.
toby
> ...
> Some time back, I was thinking that it would be nice if I knew of a
> filesystem that did automatic source control, either FreeBSD or Win32
> based. Then I could just store all the source on it, and access it as
> if it were just a directory structure.
>
> You don't happen to know of such a critter, do you?
Apart from Subversion over WebDAV, I see:
* Wayback: A User-level Versioning File System for Linux,
http://wayback.sourceforge.net/ &
http://www.usenix.org/events/usenix04/tech/freenix/cornell/cornell_html/index.html
* CopyFS, A copy-on-write, versioned filesystem,
http://invaders.mars-attacks.org/~boklm/copyfs/
* CvsFS, http://cvsfs.sourceforge.net/ "...presents the CVS contents as
mountable file system. It allows to view the versioned files as like
they were ordinary files on a disk. There is also a possibility to
check in/out some files for editing."
* Katie, "somewhat like a cross between CVS and NFS",
http://www.netcraft.com.au/geoffrey/katie/
* versionfs,
http://www.fsl.cs.sunysb.edu/docs/versionfs-fast04/index.html ,
http://www.fsl.cs.sunysb.edu/project-versionfs.html ,
http://www.fsl.cs.sunysb.edu/docs/versionfs-msthesis/index.html - not
sure if source is published
* ext3cow, "a time-shifting file system implemented with copy-on-write
(COW) and based on the very popular ext2/ext3 file system",
http://www.ext3cow.com/
* Elephant for FreeBSD,
http://www.hpl.hp.com/personal/Alistair_Veitch/papers/elephant-hotos/index.html
For non-automatic versioning, there are snapshotting facilities built
into various filesystems including Solaris UFS and Sun's new ZFS.
ArarghMai...@not.at.arargh.com
wrote:
>CBFalconer wrote:
I have:
1.1 source (Ron Cain)
2.1, 2.2 (Hendrix) usually found as "smallc2?.zip"
3.0, 3.1 (Someone else) found as "smallc3?.zip"
And a couple of other odd versions.
All found on the web, over the last 10 years.
ArarghMai...@not.at.arargh.com
Charles Richmond
Small C was published in the May, June and July issues of 1980 in
Dr. Dobb's magazine.
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Brian Inglis
Richmond <rich...@comcast.net> wrote:
>Peter Flass wrote:
>>
>> CBFalconer wrote:
>>
>> > ArarghMai...@NOT.AT.Arargh.com wrote:
>> >
>> >>>ArarghMai...@NOT.AT.Arargh.com wrote:
>> >>>
>> >
>> > ... snip ...
>> >
>> >>>>this one:
>> >>>>Small-C Compiler
>> >>>>Copyright 1982, 1983, 1985, 1988 J. E. Hendrix
>> >>>>
>> >
>> > ... snip ...
>> >
>> >>Actually I seem to have several versions of 'Small-C' compilers.
>> >>The one I mentioned above is not the one that I was thinking of
>> >>when I wrote the following paragraph. The version I was thinking
>> >>of is: "small-c:PC compiler by Ron Cain"
>> >
>> >
>> > Ron Cain was the originator, who then retired from the field. I
>> > always felt that the seizure by Hendrix was not right, although he
>> > did make improvements.
>> >
>>
>> I remember that Doctor Dobbs Journal published the source (1.1?) in, I
>> believe, three parts, for the user to key in themselves. I think I kept
>> these issues somewhere.
>>
>I can't put my hands on the issues right now...but I think Ron Cain's
>Small C was published in the May, June and July issues of 1980 in
>Dr. Dobb's magazine.
Also reprinted in "Dr.Dobb's Toolbook of C", by the Editors of
Dr.Dobb's Journal, Brady, 1986.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Michael Meissner
> Hi,
>
> In their paper, "Portability of C Programs and the UNIX System", S.C.
> Johnson and Dennis Ritchie write,
>
> \\
> Even before the idea of moving UNIX occurred to us, it was clear that C
> was successful enough to warrant production of compilers for an
> increasing variety of machines. Therefore, one of the authors (SCJ)
> undertook to produce a new compiler intended from the start to be
> easily modified. This new compiler is now in use on the IBM System/370
> under both OS and TSS, the Honeywell 6000, the
> Interdata 8/32, the SEL86 the Data General Nova and Eclipse, the DEC
> VAX11/780, and a Bell System processor. Versions are in progress for
> the Intel 8086 microprocessor and other machines.
> //
>
> Do any of these ports of pcc or pcc2 still exist? I am interested in
> the Nova/Eclipse versions in particular.
Speaking as the person who was one of the primary authors of the C front for
the MV/Eclipse, I have severe doubts PCC could generate code for the DG
machines with their concept of word pointers and byte pointers, and the severe
lack of registers.
--
Michael Meissner
email: mrm...@the-meissners.org
http://www.the-meissners.org
toby
I imagine it would have required quite a bit of surgery to do so, yes -
but Dennis' paper I quoted* does claim such a beast existed. I wish we
could find a copy floating in formaldehyde somewhere, so we could
marvel at it.
* http://cm.bell-labs.com/cm/cs/who/dmr/portpap.html
Bruce Ray
Quick notes:
IPT (Information Processing Techniques) sold a C compiler for Data General
Nova, Eclipse and MVs systems during the 1980s. It ran under the RDOS, AOS
and AOS/VS operating system, and generated code that could be used on any
Nova, Eclipse or MV.
IPT also sold a UNIX system that ran on DG Eclipse computers.
The IRIS system from EDS / Point 4 (Educational Data Systems) usually ran
nonstandard disk and multiplexor devices from 3rd party vendors, and SimH
does not [yet] support these devices.
Bruce
Bruce Ray
Wild Hare Computer Systems, Inc.
b...@WildHareComputers.com
...preserving the Data General legacy: www.NovasAreForever.com
"toby" <to...@telegraphics.com.au> wrote in message
news:1145627720....@v46g2000cwv.googlegroups.com...
> Hi,
>
> In their paper, "Portability of C Programs and the UNIX System", S.C.
> Johnson and Dennis Ritchie write,
>
> \\
> Even before the idea of moving UNIX occurred to us, it was clear that C
> was successful enough to warrant production of compilers for an
> increasing variety of machines. Therefore, one of the authors (SCJ)
> undertook to produce a new compiler intended from the start to be
> easily modified. This new compiler is now in use on the IBM System/370
> under both OS and TSS, the Honeywell 6000, the
> Interdata 8/32, the SEL86 the Data General Nova and Eclipse, the DEC
> VAX11/780, and a Bell System processor. Versions are in progress for
> the Intel 8086 microprocessor and other machines.
> //
>
> Do any of these ports of pcc or pcc2 still exist? I am interested in
> the Nova/Eclipse versions in particular.
>
> --Toby
>
