Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Job posting to reverse engineer a PDP-10 assembler

529 views
Skip to first unread message

John Levine

unread,
Jul 27, 2020, 8:42:36 PM7/27/20
to
Seen on alt.sys.pdp11 but obviously belongs here. It seems real, wonder what sort
of (cross?) assembler is worth reverse engineering 30 years later.

I think this Infocom LLC is the one in Dubai.

https://www.fossjobs.net/job/10226/specification-writer-at-infocom-llc/

---------------------------------

FREELANCE Specification Writer

Published at 18.07.2020 - Viewed: 549 times - Infocom LLC (Worldwide/Remote)

This is part of a clean room reverse engineering project. This
position operates outside the clean room.

In this position you will be provided with the source code for a
proprietary assembler that consists of slightly under 4,000 lines of
code. The source code you will study was written in assembly language
to run on the TOPS-20 operating system on the PDP-10 mainframe
computer. You will need know this assembly language or be willing to
learn. It is likely that you will need to install an emulator to run
TOPS-20 and to build and run the assembler so as to further study the
software. Candidates that already have this knowledge are preferred
but it is acknowledged that such people can be difficult to find for
such legacy systems.

In this position you will play an important role by writing a
functional specification document that describes the functions,
program flow, error handling, and other information of the assembler
that the person operating inside the clean room will need to know to
develop a compatible replacement program. The replacement program is
expected to be able to process the same input files and to generate
bit-identical output files.

You will be expected to work with an attorney who will review the
documentation to ensure that no copyrightable information is included
in what goes into the clean room. This may include sending the
documentation back to you along with feedback asking for revisions.

The final specification will be made available under GPL-3.0-or-later.
The software developed inside the clean room will be released under
AGPL-3.0-or-later.

You can be located anywhere in the world and you can choose your own
hours, as long as requirements are met.

Qualifications:

* Proven working experience in technical writing of software documentation
* Computer programming background
* Knowledge of editors and tools
* Excellent communication and writing skills in English
* Demonstrated ability to produce high-quality documentation
* Able to work independently

Applications must be submitted via email to frontdesk at infocom.xyz.
A complete application should include a résumé, cover letter with
salary expectations, and a writing sample (1000 words or less.)

All materials must be in a free format (such as plain text, PDF, or
OpenDocument, and not Microsoft Word). Email submissions that do not
follow these instructions will probably be overlooked.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Rich Alderson

unread,
Jul 28, 2020, 9:19:38 PM7/28/20
to
John Levine <jo...@taugh.com> writes:

> Seen on alt.sys.pdp11 but obviously belongs here. It seems real, wonder what sort
> of (cross?) assembler is worth reverse engineering 30 years later.

And applied for...

--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

John Levine

unread,
Jul 28, 2020, 11:03:44 PM7/28/20
to
In article <mdd5za7...@panix5.panix.com> you write:
>John Levine <jo...@taugh.com> writes:
>
>> Seen on alt.sys.pdp11 but obviously belongs here. It seems real, wonder what sort
>> of (cross?) assembler is worth reverse engineering 30 years later.
>
>And applied for...

If you get to the point of finding out details and it's not a big
secret, please tell us what makes this unlikely project worth it to
them.

Scott Lurndal

unread,
Jul 29, 2020, 12:01:09 PM7/29/20
to
John Levine <jo...@taugh.com> writes:
>In article <mdd5za7...@panix5.panix.com> you write:
>>John Levine <jo...@taugh.com> writes:
>>
>>> Seen on alt.sys.pdp11 but obviously belongs here. It seems real, wonder what sort
>>> of (cross?) assembler is worth reverse engineering 30 years later.
>>
>>And applied for...
>
>If you get to the point of finding out details and it's not a big
>secret, please tell us what makes this unlikely project worth it to
>them.

Given that the posting is from infocom-llc, perhaps they want
to cleanroom re-engineer the infocom engine (that zork et. al. used).

John Levine

unread,
Jul 29, 2020, 3:11:25 PM7/29/20
to
In article <73hUG.28027$RN....@fx13.iad>,
Scott Lurndal <sl...@pacbell.net> wrote:
>>If you get to the point of finding out details and it's not a big
>>secret, please tell us what makes this unlikely project worth it to
>>them.
>
>Given that the posting is from infocom-llc, perhaps they want
>to cleanroom re-engineer the infocom engine (that zork et. al. used).

I think this is a different Infocom LLC in Dubai.

The Infocom that wrote games was in Cambridge MA and was sold to Activision in 1986.

There is yet another Incocom LLC in Colorado which says it does
computer games but although it has a similar logo it's not evident
what if any connection it has to the old Cambridge company. The old
company's trademark was cancelled in the 1990s.

gah4

unread,
Sep 13, 2020, 1:53:42 PM9/13/20
to
On Wednesday, July 29, 2020 at 12:11:25 PM UTC-7, John Levine wrote:

(snip)

> There is yet another Incocom LLC in Colorado which says it does
> computer games but although it has a similar logo it's not evident
> what if any connection it has to the old Cambridge company. The old
> company's trademark was cancelled in the 1990s.

infocom.xyz seems to be the one in Colorado, and seems interested
in DRM free games.

https://infocom.xyz/about.html

One question might be whether you need a DRM free assembler do assemble
DRM free games. It seems, though, that they want everyone to be able to modify
their games, which means that they will need an assembler for them.

For some reason that I don't remember, I was trying out a chess program that
runs on a PDP-10 not so long ago. I have no idea, though, which games Infocom
would be interested in.


fishtoprecords

unread,
Sep 14, 2020, 4:03:58 PM9/14/20
to
Was there ever a Macro-20? Or was all the work really done with Macro-10?

I assume that the person writing the job position doesn't understand the difference between a pure assembler (that does one-to-one conversion of text to binary) with a Macro that can do the work of a pure assembler plus all sorts of bizarre macro substitutions and manipulations.

I remember talking to a LCG technical lead-level engineer not long before the death of Jupiter. He said that they had long before decided to not touch Macro-10 because it has so many weird side effects of expression expansions that were critical to the monitor, exec and a lot of the legacy CUSPs and layered products, that they didn't have time to do the regression testing. And there wasn't much of a demand for cool new features.

gah4

unread,
Sep 15, 2020, 9:35:39 PM9/15/20
to
On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:
> Was there ever a Macro-20? Or was all the work really done with Macro-10?

The numbering is strange. They are all PDP-11's, but some run TOPS-20.

I believe that the langauge is Macro-10 in both cases, though the actual
coding will be different, for OS specific calls.

> I assume that the person writing the job position doesn't understand the difference between a pure assembler (that does one-to-one conversion of text to binary) with a Macro that can do the work of a pure assembler plus all sorts of bizarre macro substitutions and manipulations.

The language is called Macro-10 and the processor is named Macro-10.
That is true whether or not macros are used.

It looks to me that the poster has some game programs that they want to be able
to assemble, to distribute, and for the distributees to be able to modify and assemble.

It has to at least do what Macro-10 does for those programs.

(snip)

John Levine

unread,
Sep 16, 2020, 11:38:40 AM9/16/20
to
In article <e9327bce-a171-4f32...@googlegroups.com>,
gah4 <ga...@u.washington.edu> wrote:
>On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:
>> Was there ever a Macro-20? Or was all the work really done with Macro-10?
>
>The numbering is strange. They are all PDP-11's, but some run TOPS-20.

I assume you mean PDP-10's. I gather the microcode for TOPS-10 and TOPS-20
was different but I don't know how.

On the other hand, I can't think of any reason for the assembler language to
be different. Adding a few new mnemonics for UUOs or JSYS doesn't make it
a different asembler.

Questor

unread,
Sep 17, 2020, 3:06:35 AM9/17/20
to
On Mon, 14 Sep 2020 13:03:57 -0700 (PDT), fishtoprecords <pat2...@gmail.com>
wrote:
>Was there ever a Macro-20?

No.

>Or was all the work really done with Macro-10?

Yes. The only difference was the symbols being used, either for UUOs or JSYS
calls and their arguments. It was just called MACRO on both sides of the
hallway, unless you really needed to make the distinction clear. But no one
ever said MACRO-20.
That's essentially correct. As the overwhelming majority of TOPS-10/20 software
was written in MACRO for many years, it was very much the foundation of
everything the software groups did. There was an understandable reticence to
make any changes. "If it ain't broke, don't fix it" was the guiding maxim.

Most of the software I worked on didn't use very complicated macros. But there
was one configuration utility that was largely table driven. The programmer(s)
who wrote it used a lot of complicated nested macros to generate the data tables
and their associated procedural code. Mostly what I remember is how it really
chewed up both the CPU and the wall clock time in order to compile.

Questor

unread,
Sep 17, 2020, 3:08:15 AM9/17/20
to
On Wed, 16 Sep 2020 15:38:39 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>In article <e9327bce-a171-4f32...@googlegroups.com>,
>gah4 <ga...@u.washington.edu> wrote:
>>On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:
>>> Was there ever a Macro-20? Or was all the work really done with Macro-10?
>>
>>The numbering is strange. They are all PDP-11's, but some run TOPS-20.
>
>I assume you mean PDP-10's. I gather the microcode for TOPS-10 and TOPS-20
>was different but I don't know how.

Paging comes to mind as one example. The TOPS-20 PMAP bug had to be fixed in
microcode.

I had one bug that occurred when the microcode was changed. I had to track it
down in a hurry before they updated the microcode in all the other machines in
the lab. It turned out this utility had an error in one of its byte pointers.
It pointed to an nonexistent page high in the address space. With the old
microcode, the page was allocated, a page table entry created, and the byte was
stashed, available for subsequent reading and writing. The utility goes on its
merry way. The new microcode returned a nonexistent page error. The utility
was written in BLISS, and the problem was... a missing period in the expression
that created the byte pointer. (Perhaps the biggest mistake in BLISS was using
a period as the contents operator.) I don't recall why this change was made to
the microcode.


>On the other hand, I can't think of any reason for the assembler language to
>be different. Adding a few new mnemonics for UUOs or JSYS doesn't make it
>a different asembler.

It wasn't. Although at this remove, I can't even say for certain whether it ran
with PA1050 under TOPS-20 or not.

Lars Brinkhoff

unread,
Sep 17, 2020, 4:36:43 AM9/17/20
to
Questor wrote:
> fishtoprecords wrote:
>>Was there ever a Macro-20?
> No.

Information online seem to imply there was a LINK-20. Is that right,
and if so what is the difference to LINK-10? Support for extended
addressing?

> As the overwhelming majority of TOPS-10/20 software was written in
> MACRO for many years, it was very much the foundation of everything
> the software groups did. There was an understandable reticence to
> make any changes. "If it ain't broke, don't fix it" was the guiding
> maxim.

A DEC-20 clone maker based in Redmond talked about updating MACRO and
LINK to support long file names. I don't know if they went through
with it.

Sam Weiner

unread,
Sep 17, 2020, 8:11:54 PM9/17/20
to
In article <5f630abf...@news.dslextreme.com>,
Questor <use...@only.tnx> wrote:
>On Wed, 16 Sep 2020 15:38:39 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>>In article <e9327bce-a171-4f32...@googlegroups.com>,
>>gah4 <ga...@u.washington.edu> wrote:
>>>On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:
>>>> Was there ever a Macro-20? Or was all the work really done with Macro-10?
>>>
>>>The numbering is strange. They are all PDP-11's, but some run TOPS-20.
>>
>>I assume you mean PDP-10's. I gather the microcode for TOPS-10 and TOPS-20
>>was different but I don't know how.
>
>Paging comes to mind as one example. The TOPS-20 PMAP bug had to be fixed in
>microcode.
>
>I had one bug that occurred when the microcode was changed. I had to track it
>down in a hurry before they updated the microcode in all the other machines in
>the lab. It turned out this utility had an error in one of its byte pointers.
>It pointed to an nonexistent page high in the address space. With the old
>microcode, the page was allocated, a page table entry created, and the byte was
>stashed, available for subsequent reading and writing. The utility goes on its
>merry way. The new microcode returned a nonexistent page error. The utility
>was written in BLISS, and the problem was... a missing period in the expression
>that created the byte pointer. (Perhaps the biggest mistake in BLISS was using
>a period as the contents operator.) I don't recall why this change was made to
>the microcode.

[smw] The old rule for BLISS was if you have a strange problem, add a dot or
remove a dot :-)

[smw] Other than that, I found BLISS, especially BLISS-36, an interesting
language to use for almost a decade.

Sam

artk...@gmail.com

unread,
Sep 18, 2020, 12:04:18 PM9/18/20
to
This sounds like they need to reverse engineer a game engine compiler, or even just compiled FORTRAN code for an ADVENT like game.

Without the source code, even ADVENT would be a non-trivial thing to reverse engineer if you didn't know how it worked internally beforehand.

Rich Alderson

unread,
Sep 19, 2020, 8:57:07 PM9/19/20
to
use...@only.tnx (Questor) writes:

> On Wed, 16 Sep 2020 15:38:39 -0000 (UTC), John Levine <jo...@taugh.com>
> wrote:

>> In article <e9327bce-a171-4f32...@googlegroups.com>,
>> gah4 <ga...@u.washington.edu> wrote:

>>> On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:

>>>> Was there ever a Macro-20? Or was all the work really done with Macro-10?

>>> The numbering is strange. They are all PDP-11's, but some run TOPS-20.

>> I assume you mean PDP-10's. I gather the microcode for TOPS-10 and TOPS-20
>> was different but I don't know how.

> Paging comes to mind as one example. The TOPS-20 PMAP bug had to be fixed in
> microcode.

[ snip ]

>> On the other hand, I can't think of any reason for the assembler language to
>> be different. Adding a few new mnemonics for UUOs or JSYS doesn't make it
>> a different asembler.

> It wasn't. Although at this remove, I can't even say for certain whether it
> ran with PA1050 under TOPS-20 or not.

Macro-10 uses Tops-10 I/O UUOs, as well as a number of CALLI UUO calls, so it
most assuredly required PA1050 to run at all on a TOPS-20 system. Ask me in
private if you want to know why I know this detail intimately.

fishtoprecords

unread,
Sep 19, 2020, 9:43:39 PM9/19/20
to
On Saturday, September 19, 2020 at 8:57:07 PM UTC-4, Rich Alderson wrote:
> Macro-10 uses Tops-10 I/O UUOs, as well as a number of CALLI UUO calls, so it
> most assuredly required PA1050 to run at all on a TOPS-20 system. Ask me in
> private if you want to know why I know this detail intimately.

PA1050 got a lot of bad press, and there was a lot of pressure to replace it with native 20 code. But for things like linearly reading a source file it was not slower, it was fairly well written and I bet optimized over the years.

Thomas Moser

unread,
Sep 20, 2020, 11:08:02 AM9/20/20
to
TOPS-20 had a project to rewrite the EXEC to be native. The “improvement” was less than 1%

Questor

unread,
Sep 30, 2020, 4:34:59 PM9/30/20
to
On 19 Sep 2020 20:57:05 -0400, Rich Alderson <ne...@alderson.users.panix.com>
wrote:
>use...@only.tnx (Questor) writes:
>>On Wed, 16 Sep 2020 15:38:39 -0000 (UTC), John Levine <jo...@taugh.com>
>>wrote:
>>>In article <e9327bce-a171-4f32...@googlegroups.com>,
>>>gah4 <ga...@u.washington.edu> wrote:
>>>>On Monday, September 14, 2020 at 1:03:58 PM UTC-7, fishtoprecords wrote:
>>>>>Was there ever a Macro-20? Or was all the work really done with Macro-10?
>
>>>>The numbering is strange. They are all PDP-11's, but some run TOPS-20.
>
>>>I assume you mean PDP-10's. I gather the microcode for TOPS-10 and TOPS-20
>>>was different but I don't know how.
>
>>Paging comes to mind as one example. The TOPS-20 PMAP bug had to be fixed in
>>microcode.
>
>[ snip ]
>
>>>On the other hand, I can't think of any reason for the assembler language to
>>>be different. Adding a few new mnemonics for UUOs or JSYS doesn't make it
>>>a different asembler.
>
>>It wasn't. Although at this remove, I can't even say for certain whether it
>>ran with PA1050 under TOPS-20 or not.
>
>Macro-10 uses Tops-10 I/O UUOs, as well as a number of CALLI UUO calls, so it
>most assuredly required PA1050 to run at all on a TOPS-20 system. Ask me in
>private if you want to know why I know this detail intimately.

Oh, I believe you. Facts I once would have recited without hesitation are now
recalled with a measure of uncertainty. I look at manuals and source files
online and get reminded of how much I've forgotten. It's a wonder I remember as
much as I do.

Sid Maxwell

unread,
Oct 1, 2020, 9:27:20 AM10/1/20
to
On Wednesday, September 30, 2020 at 4:34:59 PM UTC-4, Questor wrote:
> Oh, I believe you. Facts I once would have recited without hesitation are now
> recalled with a measure of uncertainty. I look at manuals and source files
> online and get reminded of how much I've forgotten. It's a wonder I remember as
> much as I do.
Amen!

artk...@gmail.com

unread,
Oct 1, 2020, 4:04:24 PM10/1/20
to
On Wednesday, September 30, 2020 at 4:34:59 PM UTC-4, Questor wrote:
> It's a wonder I remember as much as I do.

Where's that damned like button...

John H. Reinhardt

unread,
Oct 2, 2020, 11:54:20 AM10/2/20
to
On 9/30/2020 3:34 PM, Questor wrote:

> Oh, I believe you. Facts I once would have recited without hesitation are now
> recalled with a measure of uncertainty. I look at manuals and source files
> online and get reminded of how much I've forgotten. It's a wonder I remember as
> much as I do.
>

Heh. I've Googled and found posts I made 10 or 15 years ago about a topic and I look at it and think "I knew that once???"

--
John H. Reinhardt

Questor

unread,
Oct 4, 2020, 4:16:40 PM10/4/20
to
>was less than 1%.

I am confused. Are you talking about the TOPS-20 EXEC -- i.e., the command
processor? Wasn't it always written with JSYSes and not UUOs?

fishtoprecords

unread,
Oct 5, 2020, 10:03:56 PM10/5/20
to
On Sunday, October 4, 2020 at 4:16:40 PM UTC-4, Questor wrote:
> On Sun, 20 Sep 2020 08:08:01 -0700 (PDT), bigmo...@gmail.com wrote:
> >TOPS-20 had a project to rewrite the EXEC to be native. The "improvement"
> >was less than 1%.
>
> I am confused. Are you talking about the TOPS-20 EXEC -- i.e., the command
> processor? Wasn't it always written with JSYSes and not UUOs?

That clanged on me as well. I came into TOPS-20 in 1977, I think that was Tops-20 Release 2 (or maybe 3)
It was clearly written with JSYSae and not UUO from the first time I looked at the EXEC source code.

I don't know the earlier history. I was on Tops-10 before 77, all the pure Tenex days, etc. But from the first time I saw it, it was not using UUOs or PA1050

artk...@gmail.com

unread,
Oct 6, 2020, 10:20:18 AM10/6/20
to
On Monday, October 5, 2020 at 10:03:56 PM UTC-4, fishtoprecords wrote:
> On Sunday, October 4, 2020 at 4:16:40 PM UTC-4, Questor wrote:
> > On Sun, 20 Sep 2020 08:08:01 -0700 (PDT), bigmo...@gmail.com wrote:
> > >TOPS-20 had a project to rewrite the EXEC to be native. The "improvement"
> > >was less than 1%.
> >
> > I am confused. Are you talking about the TOPS-20 EXEC -- i.e., the command
> > processor? Wasn't it always written with JSYSes and not UUOs?
> That clanged on me as well. I came into TOPS-20 in 1977, I think that was Tops-20 Release 2 (or maybe 3)
> It was clearly written with JSYSae and not UUO from the first time I looked at the EXEC source code.

Speaking out of turn, but I took that statement to mean PA1050 was rewritten and it only improved <1%

fishtoprecords

unread,
Oct 6, 2020, 7:06:19 PM10/6/20
to
On Tuesday, October 6, 2020 at 10:20:18 AM UTC-4, artk...@gmail.com wrote:
> Speaking out of turn, but I took that statement to mean PA1050 was rewritten and it only improved <1%

I can't see this meaning. PA1050 was always written calling JSYS. It essentially converted the TOPS-10 monitor UUOs to local UUOs and then implemented them. I can't see what kind of "rewritten" could be done, as the essence of PA1050 was to implement a PDP-10 model 50 in Tenex (i.e. using JSYS).

Rich Alderson

unread,
Oct 7, 2020, 2:24:21 PM10/7/20
to
That's "emulate a PDP-10 running the 10/50 (multiuser, swapping) monitor". The
same hardware could run any of five monitors (10/10, 10/20, 10/30, 10/40, or
10/50), although only 10/30, 10/40, and 10/50 were actually sold--the other two
were paper tape only "paper" systems to appease KO.

fishtoprecords

unread,
Oct 8, 2020, 2:11:46 PM10/8/20
to
On Wednesday, October 7, 2020 at 2:24:21 PM UTC-4, Rich Alderson wrote:
> That's "emulate a PDP-10 running the 10/50 (multiuser, swapping) monitor". The
> same hardware could run any of five monitors (10/10, 10/20, 10/30, 10/40, or
> 10/50), although only 10/30, 10/40, and 10/50 were actually sold--the other two
> were paper tape only "paper" systems to appease KO.

When the drum on our (First Data) KA was being flakey, we would joke that we would switch
to swapping onto high speed paper tape.

artk...@gmail.com

unread,
Oct 8, 2020, 2:18:20 PM10/8/20
to
I was only tangentially involved in TOPS-20 administration back in the early 80's, being that BOCES/LIRICS was a TOPS-10 installation of 5 KS10s.

I remember roaming the ARPANET and seeing things that ran under PA1050, but I have no idea what the underlying architecture looked like. Sorry for my callous remarks ;)

Robert Boyer

unread,
Mar 5, 2021, 10:16:04 PM3/5/21
to
John Levine <jo...@taugh.com> writes:

> Seen on alt.sys.pdp11 but obviously belongs here. It seems real, wonder what sort
> of (cross?) assembler is worth reverse engineering 30 years later.
>
> I think this Infocom LLC is the one in Dubai.
>
> https://www.fossjobs.net/job/10226/specification-writer-at-infocom-llc/
>
> ---------------------------------
>
> FREELANCE Specification Writer
>
> Published at 18.07.2020 - Viewed: 549 times - Infocom LLC (Worldwide/Remote)
>
> This is part of a clean room reverse engineering project. This
> position operates outside the clean room.


Late follow up but does anyone know how this panned out for anyone that
applied? When I first saw this I thought it would be a perfect fit for a
Haskell program AS the functional doc with the added benefit of actually
working to provide not only the spec but also the final goal.

I didn't bother to apply as the PDP-10 was/is certainly not in my top 10
list of things I actually know a lot about.



Sid Maxwell

unread,
Mar 6, 2021, 10:59:02 AM3/6/21
to
I'm curious, too, and I did let them know that I was both interested and capable. (I was recently doing some work on a C cross compiler for the -10.). I wasn't surprised that I missed out, though; there are much more experienced and competent folks on this mailing list than I.

-+- Sid

Lars Brinkhoff

unread,
Mar 6, 2021, 11:44:18 AM3/6/21
to
Sid Maxwell wrote:
> I was recently doing some work on a C cross compiler for the -10.

Oh, interesting! Which compiler, and when, and is it available online?

Robert Boyer

unread,
Mar 6, 2021, 8:35:32 PM3/6/21
to

What are you using for the cross compiler? LLVM-ish thing? Your own back
end? Front-end? Just curious as I've done a few semi-related things that
were not nearly as general as a C cross compiler as they were far more
related to the job referenced in this thread (ie. Make really old stuff
work without all the old tooling/hardware/etc). Back then I always
gravitated towards LISPy-solutions but having a surface knowlege of far
more modern practices for compilers and the tool chains available now I
am curious as to your approach. The more specific thinks like the thread
started with I still think are right up the alley of my old-fashioned thinking.

Paul Rubin

unread,
Mar 7, 2021, 12:32:13 AM3/7/21
to
Robert Boyer <rwb...@mac.com> writes:
> What are you using for the cross compiler? LLVM-ish thing?

There have been several PDP-10 C compilers that long predate LLVM, that
I think were home grown. One of them was written in Lisp and may have
cross compiled from a Lisp machine.

Sid Maxwell

unread,
Mar 7, 2021, 11:31:53 AM3/7/21
to
Lars, a couple of years ago, I was doing contract work to make improvements for a mutual client.

Robert, it's based on an existing front end, with massive changes (mostly) to the machine-specific parts of the existing backend. I don't think I can get too specific on the details, but I was hired to make improvements to a legacy, in-house development.

-+- Sid

Robert Boyer

unread,
Mar 7, 2021, 3:33:26 PM3/7/21
to
Was just curious about the way people doing this sort of general
cross-compiler work are doing it nowadays...

the way I would have done it (given my
limited expertise in this field with things like general purpose C
compilers) or what one might consider "state of the art"

Robert Boyer

unread,
Mar 7, 2021, 3:38:57 PM3/7/21
to
I'll take that as a fairly modern way.

Just curious. I kind of like very specialized work that is similar when
I can use tooling I find ummmm... fun (like LISP or relatives) but never
really could bare the tools for more broad applications like a general
purpose compiler. I don't think I am wired for it (or I am just too much
of an ancient assembler coder that rather do that instead or something)

Rich Alderson

unread,
Mar 7, 2021, 6:21:39 PM3/7/21
to
I applied for the job, since I have 40+ years of PDP-10 internals and systems
programming experience, am familiar with the code base they wanted to cleanroom
reengineer, and was very recently unemployed (as of 1 July 2020) when this came
up. I really wanted the job.

They sat on my resume for a month, and turned me down.

Sid Maxwell

unread,
Mar 7, 2021, 7:32:15 PM3/7/21
to
Then they definitely have rocks in their heads. I strongly suspected that (a) you (Rich) had applied, and (b) had the job so I wasn't expecting to succeed. I never even heard back, so at the very least they listened to you. I'm disappointed, though, to hear that you didn't get it.

Robert Boyer

unread,
Mar 7, 2021, 9:43:24 PM3/7/21
to
Amazing they would turn down a resume with that kind of
experience. Possibly they weren't serious??? Not that even my vivid
imagination can come up with a motivation for that sort of posting with
no intent to actually hire... except some sort of data collection effort
but to what end?

I would imagine the number of people with PDP-10 internals experience
that are interested/still working could be counted with one hand given
the limited distribution of that hardware.

Lars Brinkhoff

unread,
Mar 8, 2021, 1:05:27 AM3/8/21
to
Sid Maxwell wrote:
> Lars, a couple of years ago, I was doing contract work to make
> improvements for a mutual client.

Interesting, thanks!

Lars Brinkhoff

unread,
Mar 8, 2021, 1:12:43 AM3/8/21
to
> Robert Boyer writes:
>> What are you using for the cross compiler? LLVM-ish thing?

I do wonder if LLVM would be a better back end for PDP-10 code.
I have a distinct impression GCC isn't a very good fit.


Paul Rubin writes:
> There have been several PDP-10 C compilers that long predate LLVM, that
> I think were home grown.

- Alan Snyder's C10 done at MIT
- Kok Chen's KCC done at Stanford
- Utah PCC-20
- Sargasso C (this one still at large)

> One of them was written in Lisp and may have cross compiled from a
> Lisp machine.

I haven't heard about that one. Any details you remember?

Paul Rubin

unread,
Mar 8, 2021, 1:41:02 AM3/8/21
to
Lars Brinkhoff <lars...@nocrew.org> writes:
>> One of them was written in Lisp and may have cross compiled from a
>> Lisp machine.
> I haven't heard about that one. Any details you remember?

Web search found: https://cliki.net/Zeta-C

Paul Rubin

unread,
Mar 8, 2021, 1:43:39 AM3/8/21
to
Paul Rubin <no.e...@nospam.invalid> writes:
> Web search found: https://cliki.net/Zeta-C

Oh hmm, it looks like that compiles for the Lisp machine, not the -10.
I do believe that is the compiler I was thinking of, so I must have
gotten confused. I still seem to half-remember something about the -10.

Sid Maxwell

unread,
Mar 8, 2021, 9:30:47 AM3/8/21
to
Lars, I agree that LLVM is likely a better candidate for a PDP-10 backend, and I think it'd be an interesting exercise. I also wonder whether LCC would be a good basis, as well (perhaps somewhere between gcc and LLVM in difficulty).

John Levine

unread,
Mar 8, 2021, 10:50:17 AM3/8/21
to
In article <be4bccf3-e19b-45a4...@googlegroups.com>,
Sid Maxwell <srmax...@gmail.com> wrote:
>Then they definitely have rocks in their heads. I strongly suspected that (a) you (Rich) had applied, and (b) had the job so I wasn't expecting to
>succeed. I never even heard back, so at the very least they listened to you. I'm disappointed, though, to hear that you didn't get it.

This suggests they already knew who they were going to hire but had to go through the exercise
of pretending to do a search.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Rich Alderson

unread,
Mar 8, 2021, 4:21:44 PM3/8/21
to
John Levine <jo...@taugh.com> writes:

> This suggests they already knew who they were going to hire but had to go
> through the exercise of pretending to do a search.

My conclusion, as well.

fishtoprecords

unread,
Mar 8, 2021, 11:28:33 PM3/8/21
to
On Sunday, March 7, 2021 at 9:43:24 PM UTC-5, Robert Boyer wrote:
> I would imagine the number of people with PDP-10 internals experience
> that are interested/still working could be counted with one hand given
> the limited distribution of that hardware.

I would not say that.

While there were only some modest number of hundreds of PDP-10&20 systems
in the world, they were at many key universities with thousands of students. There were at least four major timesharing vendors with multiple PDP-10&20s competing vigorously in the late 70s into the mid-80s.

There are probably 100 folks with the skills to apply for that job, many on this usenet group.
Granted, a lot of us are retired and would not be candidates for the posted job.

I thought the work described was interesting, but I have worked for enough PHBs already and I'm enjoying my retirement.

Robert Boyer

unread,
Mar 10, 2021, 12:51:28 PM3/10/21
to
I had something far simpler than a C compiler to do and just for fun
looked into LLVM when it first became "a thing" (IE when Apple went that
way), I ended up just doing what I "usually do" = LISP or Haskell type
thing/semi DSL for the translation since the input syntax was under my
own control but ever since then I have been curious as LLVM looks like
it's a very powerful tool.

sbyr...@gmail.com

unread,
Sep 4, 2021, 10:53:17 AM9/4/21
to
There's been an effort to port GCC to TOPS-20 in the past. Got somewhat far along too, but it's not being worked on now [not crediting the author in case he wants to remain anonymous ;), but it looked like a lot of great thought was put into the effort]. I recently thought about looking at LLVM as a potential target for porting, but not sure how memory intensive it (vs GCC) is. I suppose it could start out life as a sort of cross compiler, running external to TOPS-20, and then cross-compile itself. Lots of issues would have to be solved, like figuring out how to provide access (if needed) to the include files that may reside on the 20, and how to write the .rel files back to the 20. To make things simpler to start, one might require that the compiler user have the includes present in the local file system, and that the outputs (.rel and maybe other map or listing type files) go back to the local file system. And then build some kind of automated file transfer/virtual file system (I know there is some NFS support for Twenex, but it's been a little wonky when I half-heartedly tried it).

For extra fun (easier setup and use), perhaps the compiler and necessary related tools could be packaged in a Docker image, so it's trivial and error free to get something up and running. [also toying with the idea of packaging the panda distribution in a docker image, including a way to externally to TOPS-20 define the networking info, and have that information loaded into the appropriate SYSTEM: and other files at system startup, and customizing the klt20.ini to automagically include the proper network device definition.]

Steve

Lars Brinkhoff

unread,
Sep 4, 2021, 2:28:47 PM9/4/21
to
sbyrne007 wrote:
> There's been an effort to port GCC to TOPS-20 in the past. Got
> somewhat far along too, but it's not being worked on now

I was contracted by a Redmond-based company to do the PDP-10 backend.
It seemed to work pretty well when I handed it over. It was not running
on TOPS-20 at that point, but I don't know what happened after that.

> Lots of issues would have to be solved, like figuring out how to
> provide access (if needed) to the include files that may reside on the
> 20, and how to write the .rel files back to the 20.

I used a set of scripts which emulated a cross assembler, linker, etc by
transparently FTPing files to TOPS-20 (running locally on KLH10),
processing them there, and FTPing the result back to my Linux host.

https://github.com/larsbrinkhoff/pdp10-small-libc/tree/master/bin

sbyr...@gmail.com

unread,
Sep 4, 2021, 3:33:06 PM9/4/21
to
Wow -- I had no idea these were available (ftp-do, telnet-do)! Thanks for the tip Lars!

Steve

Sid Maxwell

unread,
Sep 5, 2021, 12:40:05 PM9/5/21
to
Lars, 2-3 years ago I continued your work on that ported gcc, adding several back-end optimizations, and getting a good bit of the gcc test suite working. The scripts are still used.

To elaborate on Lars' explanation, the compiler, running on Linux, generates assembly language. The assembly files are copied to TOPS-20 and assembled and linked there.

-+- Sid

sbyr...@gmail.com

unread,
Sep 5, 2021, 4:01:42 PM9/5/21
to
Hey Sid -- this is great news! Do you have a GH repo where your work is kept that you can share?

Thanks,
Steve

Sid Maxwell

unread,
Sep 5, 2021, 6:02:00 PM9/5/21
to
> Hey Sid -- this is great news! Do you have a GH repo where your work is kept that you can share?

I'm sorry, no. The work was done under contract, and the company holds the rights.

-+- Sid

sbyr...@gmail.com

unread,
Sep 5, 2021, 7:51:38 PM9/5/21
to
Ok -- thanks for the quick reply! Good to know it is doable (existence proof).

Steve

Paul Rubin

unread,
Sep 5, 2021, 8:44:07 PM9/5/21
to
Sid Maxwell <srmax...@gmail.com> writes:
> I'm sorry, no. The work was done under contract, and the company
> holds the rights.

Um ok, but it's GCC which is GPL, so I hope the company releases
whatever there is of the port.

Scott Lurndal

unread,
Sep 9, 2021, 2:50:24 PM9/9/21
to
If they're using it internally, they have no obligation to release
the port to anyone.

If they provide the gcc binary to anyone, then the GPL kicks in.

0 new messages