Re: [Tack-devel] Bare metal PDP-11 developer toolchain

[David G. <dg...@co...>]

Hello,

The ACK doesn't really like using the compiler configured for one
platform to generate code for another --- the code generator is
allowed to produce platform-dependent code. For example, the 8080 code
generator by default generates calls to helpers via RSTs and of course
these need to be configured for your platform.

So, the _right_ thing to do is to add a new plat for your bare-metal
architecture. See plat/pc86 for a really simple one which produces
bootable PC floppies. include should be obvious, libsys contains the
system call library (mostly stubs in C, you can just copy these) and
boot.s is the startup code; you'll want to copy most of the pdpv7 one.
descr is the actual platform configuration used by the ack executable
to build programs; you can just copy the pdpv7 one with the obvious
edits. The most complex part is that you'll need to replace the cv
section --- this converts from the generate ack executable to a
platform executable; it's not done by the linker. For the pdpv7 plat
there's a custom tool, but chances are you'll want the standard aslod
tool (see man page in util/amisc/aslod.1). This just emits all the
segments in order. pc86 uses this to make a disk image.

The wrinkle here is that the PDP11 uses split I/D, and I don't know
how these get mapped to physical memory. If you can't handle with all
the data just being immediately after the code, you'll need your own
custom tool.

However... a brief look at the pdp code generator suggests that it
doesn't use any platform-specific features, so you might be able to
get away without making a new plat. You'll need to:

- compile your program, your boot.s and your libsys with ack -mpdpv7 -c ...
- invoke the led linker yourself, passing in the right -b flags for
the start address and replacing the boot.s and libsys with your custom
ones
- run aslod (or some other converter) on the result yourself

It's probably easier (and less errorprone) just to add the plat; it'll
be the same amount of work and give a much easier-to-use result.

Re getting symbol address: you can't run anm on a platform executable
but you can on an ack ack.out executable. Do this:

$ ack -mpc86 -c.out -o hilo.out examples/hilo.c
$ anm hilo.out
$ ack -mpc86 -o hilo.img hilo.out

Re getting an annotated disassembly: are you thinking of objdump?
Sadly that's one thing that the ACK doesn't have, a disassembler.


On Mon, 21 Apr 2025 at 21:05, Béla Bréda <bel...@gm...> wrote:
>
> Hello again,
>
> I'm looking for a toolchain that would allow me to develop simple programs in C for a PDP-11/05, which do not need the services of the operating system. I found several sources on the net, where different solutions were tried for this purpose, with more or less success. What I tried so far was the GCC cross-compiler with PDP-11 a.out output, partly with the newlib C library and some custom-implemented libc functions. I just made a very simple "Hello Word" test program, for which I used my own crt0 startup file and linker script. One problem is that PDP-11 support is no longer typical in modern development environments, and another problem is that even the theoretically small and simple newlib libc functions are very complicated and result in large code, which is not good for me, because on my own PDP-11/05 machine a total of 16kB of memory is available, but in the SIMH emulator only a maximum of 56kB.
> During my research I found ACK, which I liked in several ways. It is good that it has the complete libc and I like it from the point of view that the code is simple and readable and the code of libc and system functions can be easily customized. I would of course make the UNIX function call stubs so that the compiled program works without an operating system. But then ACK itself can be easily compiled and run on a modern Linux. So far, for me this is the most promising compiler to implement my idea.
> However, there are a few problems that I don't know how to solve with ACK. One is that it would be nice to have an assembly file output that shows the specific memory addresses set by the linker alongside the instructions, and the file also contains the assembly code of all external functions that the program uses, just like in the gcc output .s files. The other is that since there is no file system on the machine, instead of the a.out output, I would actually only need a binary output file that starts at address 0. At this address, there is only a jump instruction to the first instruction of crt0.
> How can I solve these with ACK?
>
> Best regards,
> Béla
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel