Forum OpenACS Q&A: compiling OMSI PASCAL programs in DEC RT57XM monitor

I'm one of the two principal authors of the old PDP-11 OMSI Pascal compiler you're referring to. I did the work under contract to ESI while in college. No development work has been done on that compiler since the late 1970s.

The compiler uses the standard RT/11 device drivers and the standard API to load and reference them. You should ask Mentec if they've modified the application-OS API. If not, drivers shouldn't be a problem.

A more likely source of the dump to ODT is memory management. Clearly this has changed since 4 MB is being made visible to the operating system and applications. The PDP-11 is a 16-bit computer and the original architecture only allowed direct reference to 64KB total, 32KB in I[nstruction] space and 32KB in D[ata] space. Obviously changes were made to make 512KB available and even more changes to make 4MB available.

He would have to re-engineer all of the interface hardware that connects the PDP-11 to the laser trimming system.

The system software that drives the low-level hardware interfaces to the laser trimmer is also written in the OMSI Pascal dialect that among other things allows for direct whacking at the hardware. He'd have to rewrite the entire system software level supplied by ESI.

First, though, he'd have to reverse-engineer that software, because he doesn't have source to it. Oops!

After doing all that he could recompile his application on the PC ...

I have only a vague understanding of what a "laser trimming system" is, but it looks big and expensive.

As for why Roger is asking here, well if I Google for OMSI Pascal, right now the 4th hit is this Don's PDP-11 Pascal compiler post! (Funny, I guess there's not a lot of info on late 1970's compilers on the web...) So he's here because of you, Don!

PDP-7 was an 18 bit descendent of DEC's first computer. That lineage goes PDP-1/7/9/15.

The 12-bit line - first personal computer available that cost less than $50,000 - goes PDP-5/8[a bunch of 8s].

Then of course there was the old 36 bit big computer that derived from Ken Olsen's graduate days at MIT ... the PDP-6/10 series.

Those were the days. Computers had lights on them, often lots of lights. And you could program them! :) :)

Nothing, though, beats the console of an old CDC 3300 that was available to me after high school. I wanted to steal the console on display at the Frei University in Berlin.

The PC took the romance out of computers ... instead of blinking lights we can program we have ... OFFICE! YUK!

There's a reason the MC 68000 assembly language looks much like the VAX's ... Gordon Bell's general register design and orthogonal instruction set for the 16-bit PDP-11 was the basis for the later VAX and also the 68K. The 68K was less orthogonal that either the PDP-11 or VAX. With these latter machines, operands could almost always be either memory or a register and the instruction set was very regular.

The PDP-11 is the only computer I'm aware of for which you can write a program which fills all memory with a copy of itself - running backwards!

mov -(pc),-(pc)

Where pc is the Program Counter, i.e. the register that points to the current instruction (actually points one word beyond as it is executing).

And of course the PDP-11 is why C has autoincrement and autodecrement operators ... they map directly onto the operand modes supported by the hardware.

Not only did Whitesmith's C compiler suck, so did the people at Whitesmith's.

Thats right r0-r15 could be address or data registers compared to a0-a7/d0-d7 on MC68000

re your comments about decrement and increment in C being direct relation to the underlying assembly language, what about LINK and UNLINK on the 68000, their main purpose was to preserve registers en-masse and really where there as far as I can see as a convenience for compiler writers!!

Still very good, if fast fading memories.

I was lucky to even get the PDP-11 experience I started with them in 1988 (aged 17), when in most other industries they where already 'OLD' technology.

Because of the lack of instruction cache, there where some amazing examples of self modifying code. ditto for the 68000. With the advent of the 68020 and associated instruction cache, such things became bad practice.

Nice trip down memory lane

We can also provide modern upgrades/replacements for the entire HP1000 product series and most Data General Nova and 16-bit Eclipse systems if anyone has an interest.

Sold quite a few disk sub-systems to Dick Jensen of ATEX back in my earlier days in the industry.