Well, this was complicated by the fact that sources are not available...
I had to write a disassembler (because the ones that other have written
couldn't deal with the object code I was looking at).
Then after the disassembler was done, I had to actually disassemble the
module I was interested in, figure out how it works, rewrite it so it
would allow concurrent use of Datatrieve-11 and DECnet, then rebuild,
create a test, and verify that all worked.
So now I have a PDP-11 disassembler for RSX object code, which is
"better" than any other I've found.
And to make that long story a bit shorter: the problem is that I am
facing object code generated by BLISS-11 or BLISS-16. Actually, I have
seen the source code that BLISS-16 generates, and I've generally been
pretty impressed by it, so I suspect this is actually from BLISS-11. It
generates some pretty stupid code, but it also takes advantage of the
rather free form TKB (the linker) allows object code to look like, and
does the object code in a very different way than any other compiler
I've seen. Basically, it creates all the code in one run, and then it
goes back and patches all of it in select locations, where needed.
The usual output from compilers is that they generate a chunk of code,
and then follow that with updates to select locations in the previous
chunk where references to symbols or expressions needs to be resolved at
link time.
The code that does all the data and then goes back and patches it all
over the place just wasn't handled nice at all by any existing
disassembler. The end result was unreadable and confusing.
My (new) disassembler now collects everything before doing any
disassembly. Requires more memory, but means this kind of object code
gets handled correctly. And of course, I try to do some more clever
things while I'm at it.
I'll probably release that disassembler as well, eventually. For now
it's still not complete. I just needed it to work enough to handle the
code I wanted to disassemble in order to fix Datatrieve-11. So now I'll
continue on the disassembler instead. :-)
And while I don't particularly enjoy writing documentation, I do think I
need to do it, or otherwise noone will at all know how to make use of
these things.
Tests are mostly done for specific things. I usually don't write that
many automated regression tests for the things I do in my spare time...
And then I try to spread my fixes. Currently my TCP/IP package is where
I do this, but it's sortof not the right way, really. I should work on a
more proper RSX and layered software patch management system instead.
Johnny
On 2022-01-24 19:56, Thomas DeBellis wrote:
Oh, I don't think you could claim the exclusive
mantle of amusing one's
self with weird things, years after the fact and I know that you
wouldn't want to.
The pity is that this is how the state of the art was sometimes
advanced, back in the day. The story of IBM's VM immediately comes to
mind. For DEC, where customers had source, you would often see somebody
getting annoyed with a particular feature, misfeature or un-feature and
wind up implementing it. And then spend years trying to get DEC to
adopt the fix.
At least for Tops-20, it has been gotten up to date enough that I have
been successfully use it for regression tests or to prove that a problem
exists. Ideas still have a way of getting around sometimes.
This is a hobby and we do what amuses us and change what annoys us (one
hesitates utter 'fix' without forethought). This leads to the DeBellis
Theory of Delayed releases:
1. It is more fun to start wring code than to fully finish writing code.
2. It is more fun to have several things going on instead of focusing
on completion of one sole thing.
3. Numbers 2. and 3. are more fun than creating a comprehensive test
battery (I'm thinking UETP)
4. Packaging a fully tested release is tedious
5. Unless you happen to have a spare degree in literature, nobody wants
to write documentation.
1. Ever
2. Even they are threatened with payment
I've got a big pile of things to document. Even when I write the manual
concurrently with the implementation (which I did for the Tops-20 FAL
anonymous functionality), it remains on the pile to somehow package up.
There is some sense of urgency for me. MRC died long before anyone would
have ever expected. A very grievous loss for me personally, because I
lost an excellent technical resource, proof-reader, critique (oh boy...)
and somebody to keep the release package up to date.
------------------------------------------------------------------------
On 1/24/22 12:46 AM, Johnny Billquist wrote:
Ok, it's highly unlikely that anyone cares, but just in case I am
posting this anyway.
When using RSX-11M-Plus, if you write a program that uses the
Datatrieve-11 callable interface over DECnet, your program cannot use
DECnet itself for anything in parallel. Which sucks. I've just done
some changes to the Datatrieve-11 call interface library, so that this
is now possible to do. Ping me if you want to know more.
I've also written a nice interface from PDP-11 C, which makes it
pretty easy to use both Datatrieve-11 and DECnet.
The weird things I amuse myself with, 20 years after anyone stopped
caring.
I should probably start writing somekind of manual with how to do
these things that are not obvious, might not be documented, or that I
might have fixed over the years...
Johnny
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol