Undefined instruction - error notification from pdp1 simulator

[Alen Shapiro]

I'm working my way through avoiding C Cross Compiler -> PDP1 issues.

I've a situation where the assembler is generated but throws a runtime error when the PDP1 simulator is applied. The error I get is:

PDP-1 simulator V3.8-1

Undefined instruction, PC: 000455 (000000)
Goodbye

after

pdp1-elf-as main.s -o main.o
pdp1-elf-ld -L/home/alien/pdp1-playground/build-gcc/gcc -o main.bin \

 -T /home/alien/pdp1-playground/common/common.ld main.o \

../common/crt0.o -lgcc

pdp1-elf-objcopy -O dec_rim main.bin main.rim
pdp1 /home/alien/pdp1-playground/common/startup.pdp1

(startup.pdp1 contains:

set cpu mdv
att ptr main.rim
boot ptr
quit

)

What's the best way to see what's at PC:000455 that's out of alignment or miscoded for the simulator? Should I try a different assembler (perhaps with a listing option)?

TIA

--Alen

[Angelo Papenhoff/aap]

Since you're using simh, you can try `e -m 455` to disassemble 455 symbolically (-m = mnemonic). but you seem to be using an ancient version of simh, i have no idea if it supports this flag.

[Alen Shapiro]

Thanks Angelo,

I reinstalled the PDP1 distribution, which does seem to include SIMH v3.8-1 as current (should we be getting a more recent SIMH in the obsolescence distribution?).

I changed startup.pdp1 to:

set cpu mdv
att ptr main.rim
boot ptr

e -m 0-4000

quit

which showed memory contents 0-2251 all zeroed out. That's the reason I'm getting "Undefined instruction".

Now I'm a bit stuck. The C Cross Compiler is based on GCC, which generates GASM assembler rather than MACRO. The various steps (listed in my original post) produce a "main.rim" file which usually loads and runs - except with this generating C code. Is it too large and its loading into some other memory segment. Should I try to disassemble this .rim to see where it is trying to load? Are there other things I should try to find out what is wrong with this .rim?

Regards,

--Alen

[Angelo Papenhoff/aap]

I'm not really interested in supporting simh, it's certainly not part of our distro. Maybe you have that (ancient) binary in your path somewhere and it's interfering? If the code of this C compiler works neither in simh nor in my emulator then that's probably a shortcoming of the compiler.

[Alen Shapiro]

Hi Angelo,

Well, that was a surprise.

I came to the PiDP-1 via PiDP-11/70, PiDP-8, and PiDP-10, all of which used simh as their emulation engines. I assumed simh was similarly employed in PiPD-1.

That's a huge project. Hat's off.

Regards,

--Alen

[Bill E]

Angelo's implementation is far easier to understand and work with than simh, imho.

He actually implements what the hardware itself did, down to using the same internal names for the flip-flops and duplicating the original subclock phases.

The bits I've added were easy to fit in without major changes.

I love it!

Bill