PDP-11 Assembly
brc...@yahoo.com
PDP-11/94 RSX-11M+ to Visual Studio 8 C++. I would like to be able to
run at least code snippets of code on a PC to help verify the now
code. I've downloaded, built and run the SIMH simulator successfully.
Also a PDP11 Emulator and Assembler. Documentation is sparce on the
net and I'm missing a couple steps.
I found hello-world.mac and echo.mac programs along with the emulator
but don't know how to run them. I assume there is an assembly and link
involved. I can assemble them OK but then what? I can't seem to find
anything on the web about linking.
Anyone that can kick me in the right direction would be my hero for
life. If I can just get helloworld to run I'll be way ahead.
Thanks, Bob Ritter, Pensacola, FL brc...@yahoo.com
Johnny Billquist
The linking process in RSX is called task building, and the program for
this is TKB. While there is a lot to be said about this subject, a short
crash course is just:
MAC <filename>=<filename>
TKB <filename>=<filename>
Assuming you are using MCR, that should do it. But of course, it then
depends on what your programs are doing if this is sufficient or not.
Once you have a .TSk file, you just run it with:
RUN <filename>
Feel free to ask more, but if you really need extensive help, please
consider paying for my time. :-)
(Yes, I do RSX consulting for a living, still...)
Oh, and depending on how the application was written, you might be
facing a big challenge porting it. RSX offers some really nice features
that are somewhat difficult to reproduce in modern OSes.
But it might also be easy. It all depends on how the software is
written, and in which language.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Brian Inglis
If the product is written in PDP-11 assembler on RSX, you'll need to
start by reading PDP-11 architecture, RSX OS, and development tool
manuals from academic or hobby sites.
Academic sites may be more likely to offer Unix hosted and emulated
systems and tools whereas the hobby sites may offer more info on the
commercial DEC OSes.
The non-VAX business was sold to Mentec which may or may not be in that
business any more so a lot of commercial materials were still owned and
legally restricted and may not be publicly available.
You may need manuals specific to the machine, peripherals, RSX version,
and other development tools used if any, as well as any technical
documentation available for the product.
--
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
johnwa...@yahoo.co.uk
Assuming the original is written in PDP11 assembler, the PDP11 has a
lovely instruction set which is nicely summarised on the PDP11
Programmers' Card which is reasonably widely available these days.
What is less widely available is documentation on the services and
facilities in the RSX11 OS family. Some of the more creative PDP11
programmers made extensive use of the MACRO facilities in the MACRO11
assembler; both DEC-supplied and user-defined macros were widely
used.
Were there any unusual interfaces involved in this trainer - stuff
which wouldn't normally be seen on a Windows PC? Bear in mind that
these days, stuff not normally seen on a Windows PC includes serial
interfaces. Although USB->serial adapters are widely available, there
are cases where USB->serial adapters are a poor substitute for a real
serial interface, eg time-critical protocols which rely on minimal-
latency short request/response sequences will not work well over a
serial->USB adapter.
If realtime responsiveness of any meaningful kind is a requirement for
this job, your customer may want to reconsider Windows as a deployment
environment. Also, the interprocess comms, synchronisation, etc,
facilities on today's OSes (eg Windows or Linux) are rather different
than on RSX.
As software rot seems to affect Windows systems much more rapidly than
it affected DEC systems, this may be a good time to think about a
"succession plan" for when Studio 8 (and/or the chosen deployment OS)
is no longer viable. Another name for "Visual Studio 8" is Visual
Studio 2005. Visual Studio 2008 has already replaced VS 2005 as far as
MS are concerned; my recollection is that you can't mix Vista and
VS2005, which may or may not be a problem for you, depending on your
deployment environment.
Basically, as Johnny has already said, there may perhaps be more to
this than meets the unfamiliar eye. Someone on the project WILL be
needing these kinds of knowledge, preferably earlier rather than
later.
Good luck anyway!
glen herrmannsfeldt
> Assuming the original is written in PDP11 assembler, the PDP11 has a
> lovely instruction set which is nicely summarised on the PDP11
> Programmers' Card which is reasonably widely available these days.
> What is less widely available is documentation on the services and
> facilities in the RSX11 OS family. Some of the more creative PDP11
> programmers made extensive use of the MACRO facilities in the MACRO11
> assembler; both DEC-supplied and user-defined macros were widely
> used.
The PDP-11 instruction set is fine for small programs, but
not so convenient addressing megabytes. The floating point
(option) isn't so bad, but S/360 is still easier.
-- glen
johnwa...@yahoo.co.uk
Cleverer people than me have said that with the right "programmable
logical address space" (?PLAS) support in the OS and hardware (which
should be the case with the hardware and OS in question here) PDP11s
were OKish up to 4MB or so, which isn't too bad for a 16bit processor.
The current application may or may not explicitly use the PLAS stuff,
but that will become clear (to those doing the job) in due course.
Johnny Billquist
Well, in a way you could say that of course you'll have problems when
needing to address huge memory sizes on a 16-bit machine.
However, that's mostly a mindset thing. It's not really difficult to
handle large amounts of data on any machine. It's just a question of
doing it in a way that fits said machine.
After all, the same problem is just as true on a 32-bit machine, when
you start dealing with databases with several gigabytes of data.
Having a cleverly designed database on disk, and caching the most
important parts are always what you need to do when you play with lots
of data.
Large programs are much the same deal. You just need to split it up into
smaller pieces, and either have those as separate smaller programs that
call each other, or use overlays. It's not really *that* difficult.
However, moving an application written for one OS to another OS can be a
huge challenge. Since the paradigms used for the design of the software
might be very different. Just look at the problems you might face
porting a Unix application to Windows. (For example, the select() call
and file descriptors for sockets mixed with file descriptors for other
type of files). There is just so many things that work different in
differens OSes.
In RSX, you have wonderful possibilities for asynchronous, event driven
programs with a granularity that can be hard to match in todays OSes.
You also have wonderful ways of sharing memory between processes, moving
the mappings around, sending messages, sending memory spaces and
triggering events in other processes. There are also great ways to get
events when strange things happens, which can be used to signal
information back and forth. And then your program might be using RMS to
get a nice file database with keys to search for.
As usual, everything in one system is possible to do in another system,
but the effort involved in getting it to work in another system might be
much more than you asked for.
RSX is really still a very good platform for doing stuff in. It's just
that so few people realize it today, since it's been out of most peoples
mind for so long. But with the hardware simulators today, using RSX on
fast, modern hardware isn't a problem. So there are times when I think
that RSX would be a better solution than the Unix or Windows solutions I
see are getting implemented. But the chance of RSX ever being used on
something new is close to zero. :-)
Oh, and manuals for RSX are actually available online. See
http://www.stromasys.ch/charon-tb/RSX11.htm
Brian Inglis
brc...@yahoo.com wrote:
FYI PDP-11 assembler -> AT&T assembler -> GNU assembler, so gas may work
pretty well right out of the box. YMMV with OS and I/O calls, but you
could possibly drop in/out of C to do those.
Johnny Billquist
> On Tue, 27 Jan 2009 11:40:17 -0800 (PST) in vmsnet.pdp-11,
> brc...@yahoo.com wrote:
>
>> I have been given the task of porting a major PDP-11 USN trainer from
>> PDP-11/94 RSX-11M+ to Visual Studio 8 C++. I would like to be able to
>> run at least code snippets of code on a PC to help verify the now
>> code. I've downloaded, built and run the SIMH simulator successfully.
>> Also a PDP11 Emulator and Assembler. Documentation is sparce on the
>> net and I'm missing a couple steps.
>>
>> I found hello-world.mac and echo.mac programs along with the emulator
>> but don't know how to run them. I assume there is an assembly and link
>> involved. I can assemble them OK but then what? I can't seem to find
>> anything on the web about linking.
>>
>> Anyone that can kick me in the right direction would be my hero for
>> life. If I can just get helloworld to run I'll be way ahead.
>
> FYI PDP-11 assembler -> AT&T assembler -> GNU assembler, so gas may work
> pretty well right out of the box. YMMV with OS and I/O calls, but you
> could possibly drop in/out of C to do those.
I'm sorry, but I don't understand that sentence at all. Do you mean that
you could assemle a program written in MACRO-11 in gas??? If so, the
answer is most definitely no.
The syntax is not the same, and gas do not support anywhere near the
same capabilities with macros as MACRO-11 do.
Brian Inglis
<b...@softjar.se> wrote:
>Brian Inglis wrote:
>> On Tue, 27 Jan 2009 11:40:17 -0800 (PST) in vmsnet.pdp-11,
>> brc...@yahoo.com wrote:
>>
>>> I have been given the task of porting a major PDP-11 USN trainer from
>>> PDP-11/94 RSX-11M+ to Visual Studio 8 C++. I would like to be able to
>>> run at least code snippets of code on a PC to help verify the now
>>> code. I've downloaded, built and run the SIMH simulator successfully.
>>> Also a PDP11 Emulator and Assembler. Documentation is sparce on the
>>> net and I'm missing a couple steps.
>>>
>>> I found hello-world.mac and echo.mac programs along with the emulator
>>> but don't know how to run them. I assume there is an assembly and link
>>> involved. I can assemble them OK but then what? I can't seem to find
>>> anything on the web about linking.
>>>
>>> Anyone that can kick me in the right direction would be my hero for
>>> life. If I can just get helloworld to run I'll be way ahead.
>>
>> FYI PDP-11 assembler -> AT&T assembler -> GNU assembler, so gas may work
>> pretty well right out of the box. YMMV with OS and I/O calls, but you
>> could possibly drop in/out of C to do those.
>
>I'm sorry, but I don't understand that sentence at all. Do you mean that
>you could assemle a program written in MACRO-11 in gas??? If so, the
>answer is most definitely no.
>The syntax is not the same, and gas do not support anywhere near the
>same capabilities with macros as MACRO-11 do.
No I meant the PDP-11 assembler instruction opcode mnemonics, formats,
and some pseudo-ops were adopted by AT&T for their assembler, ported to
some systems, and have made their way into the GNU assembler (gas),
ported to many systems.
So if you can understand or write PDP-11 assembler (with some fairly
obvious VAX-like extensions), you can probably understand or write GNU
assembler, and vice-versa.
Suggested that because it may make porting PDP-11 assembler to a
different platform somewhat easier because you can play om the target
platform.
Macro-11 is a whole other ball of wax, as are dealing with PDP-11 OS
macro libraries, but for simple assembler porting, the standalone C
preprocessor cpp would allow you to easily port simple includes and
function like macros.
Macros with internal logic would require m4 or similar to emulate.
Johnny Billquist
But the opcode mnemonics, formats and pseudo-ops are different for each
backend you code. gas for an i386 is not anywhere near PDP-11 assembler.
Not even if you use gas.
gas is not some universal assembly language, which then translates some
abstract assembly into the native form for that platform. gas is an
assembler with many different tastes.
> So if you can understand or write PDP-11 assembler (with some fairly
> obvious VAX-like extensions), you can probably understand or write GNU
> assembler, and vice-versa.
I don't agree. :-) Or, I only agree if your target platform is actually
a PDP-11 or a VAX.
> Suggested that because it may make porting PDP-11 assembler to a
> different platform somewhat easier because you can play om the target
> platform.
Good idea, but I don't think it's valid.
> Macro-11 is a whole other ball of wax, as are dealing with PDP-11 OS
> macro libraries, but for simple assembler porting, the standalone C
> preprocessor cpp would allow you to easily port simple includes and
> function like macros.
> Macros with internal logic would require m4 or similar to emulate.
Well, Macro-11 isn't necessarily tied to any OS. Any DEC OS will provide
a bunch of predefined macros to do various stuff, but you are not
required to use those.
But even more importantly, people do write their own macros as well, and
those you need to somehow transport over to any other assembler you try
to port the code to.
And I don't m4 can do the tricks that Macro-11 can, so it's not good
enough as a substitute.