Subject: PDP-8 assemblers

From: [email-masked] (John Wilson)
Date: 8 May 1994 05:18:19 GMT

I should know better than to say this (got in a flame war with cjl last
time I did :-) but, why is PAL-8 compatibility such a lofty goal?  It's
a pretty lame assembler, and it's not as if there are untold hundreds of
megabytes of PDP-8 source code available to most of us, which it would
be impossible to convert to a slightly different syntax.  If you need
PAL-8 compatibility, by all means use PAL-8.  If some other assembler
has sufficient advantages to make it worth using (like being a single-
pass assembler, or having decent literals a la MACRO-10, or producing
relocatable output), then presumably you've weighed these advantages
against the fact that the author liked ".=" or "LOC" better than "*",
or wanted to use ".END" instead of "$", or whatever, before deciding
to care one way or another.

I've about had it with "compatibility" in the PC world, who needs it
in PDP8-land.  When I got TASM the box said "100% compatible with
MASM V4.0 and V5.1" on it, and the first program I tried it on (which
assembled without errors under MASM V5.1) triggered many dozens of
error messages.  It took me about a day to get it conditionalized so
that both assemblers would like it.  Why bother?  I'd much rather make
a clean break and blow off compatibility in favor of correcting some
of the basic sillinesses in MASM's design.  If I found (or wrote) an
assembler that did all these things right, I'd gladly spend a week
or two reediting all my programs (probably with a lot of help from
a simple BASIC program, like the syntax would really be that different)
to use the better assembler.

And as Doug pointed out, if your goals are modest why sweat over the
assembler?  I wrote a lousy PDP-8 cross assembler when I was a freshman
(and had unlimited free electricity!) so that I could upload code from
my PDT-11/150 into my PDP-8/E, and the only neat thing about it was that
it worked at all (my PDP-8 peripherals were all 150 miles away so so
much for PAL/D), but so what?  I *like* to put dots on the beginning
of ".TEXT" and ".PAGE", and I consider generating a BIN "org" record
for every "*" command even if no data are generated to be a bug, not
a feature, but no one else will ever use the assembler anyway.

John

---

From: [email-masked] (PDP11 Hacker .....)
Date: Sun, 8 May 1994 14:45:00 GMT

In article <[email-masked]>, [email-masked] (John Wilson) writes...
>time I did :-) but, why is PAL-8 compatibility such a lofty goal?  It's

I fully agree with you. The reason I wanted Doug's assembler was not to avoid
getting a real assembler/operating system/disk for my PDP8e, but to assemble
little test programs to sort out the hardware that I've got, so that I know it
will work correctly. It sure beats hand-assembling :-)
Incidentally, I know it's a cause of flames to mention PC's on this newsgroup,
but Doug's assembler will compile and run (I think correctly) under Microsoft
QuickC v2.5 on a PC. No changes needed.

>be impossible to convert to a slightly different syntax.  If you need

Most of these sytanx changes can be fixed by running sed on the source file,
and then fixing up any errors that come on assembly. OK, so it would be a pain
for something like an operating system source, but in that case, why not use
PAL8. It's not like you're limited to one assembler for all programs...

>John
-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.

---

From: [email-masked] (Charles Lasner)
Date: 9 May 1994 13:01:02 GMT

In article <[email-masked]>,
John Wilson <[email-masked]> wrote:
>time I did :-)

True!  So this time the entire world of alt.sys.pdp8 is gonna hear it :-)

> but, why is PAL-8 compatibility such a lofty goal?

Because it's a standard language.  I suppose that every time you wanted 
to write something in FORTRAN, you put your project on hold and instead 
decided what you personally didn't like about F66/F77/F8whatever, then 
spent untold hours coming up with a non-standard implementation of a 
compiler that no one else wants to use, *then* proceeded to write your 
original program in that newly-created incompatible language?

If the particulars of a project seem to indicate that there is a weakness 
in the otherwise language of choice, then it's good practice to get the 
job done anyway, and document what tedium it is to accomplish that sort 
of problem.  At a later time, you can consider mapping out or even 
implementing that which would have made the job (now done!) easier to do 
at the time.  Perhaps there will even be a next time where you'll get 
additional benefit from the effort.  Perhaps, in documenting it, others 
will see the wisdom of your variant design.  But in the mean time, by not 
getting the current project accomplished, you are internally 
side-tracking yourself, etc.

>  It's
>be impossible to convert to a slightly different syntax.

Well, there aren't untold megabytes, but rather there are very-well-told 
megabytes!  In fact, we are starting to accumulate quite a bit of PDP-8 
source code.  I personally have over 1 million lines of code, and that's 
just from me over a 25+ year period.  Towards what end, assuming there 
was some purpose in doing so, is it useful to convert this stuff?

>  If you need
>PAL-8 compatibility, by all means use PAL-8.

No, I don't need PAL-8 compatibility; I need PAL-8 functionality.  I 
consider PAL-8 barely functional for my needs.  Often, it's getting in my 
way.

>  If some other assembler
>pass assembler,

I find no particular up-side to single-pass assemblers.  The time spent in
fixing up the forward references, possibly coupled with some load-time
consequences, I find to be of no advantage, rather, I find that it could
approach the more predictable "overhead" of a clean second-pass approach. 
Moreover, it means the listing has less info in it unless it's a
second-pass listing, which is what I do anyway when I need one.  Why would
I want a listing that differs from the binary (unless I want to do manual
calculations)? So, a one-pass assembler is just too quirky for me.  But 
there's a larger issue: a one-pass assembler lacking nothing else 
relative to PAL8 just doesn't exist!  Are you saying that PAL8 
compatibility must be avoided at all costs, even if it means I should 
drop everything and go write a one-pass asm that I also don't want?

> or having decent literals a la MACRO-10,

That's a very nice cute feature.  I would like it incorporated into PAL8, 
but I don't expect it to happen real soon.  In any case, it's not a high 
priority on my list of what I need an assembler to do.  I welcome it 
rather than require it.  However, note that this is one of those quick 
and dirty techniques (not the implementing of it, but rather the using of 
it!), and doesn't really apply to much of what I do.

> or producing
>relocatable output),

Relocatable output I consider a negative feature on the PDP-8.  This 
machine's address space is so small that I am "familiar" with every bit 
of storage.  A level of abstraction where the code goes where someone 
other than me is putting it there means I'm not exactly programming an -8 
anymore!  Others will argue against this.  However, they have a differing 
set of goals from me.  Their programs are also longer than mine for the 
same level of functionality, etc.  I don't share their enthusiasm for 
expediency either.

If you use a compiler of a high-level language, you have already 
abdicated caring about efficiency.  By all means use relocatable output; 
it makes the compiler design miles easier to achieve.  No one expects 
compiler-generated code to match the efficiency of hand-created code.  
But I write in -8 assembler, not in the assembler of an "almost" -8 whose 
addressing rules are relaxed somewhat, but only towards the goal of 
making a relocatable-oriented binary system, etc.

BTW, there is an assembler for the -8 called PAGE8.  Besides the fact 
that it has IBM/360-type syntax, it has a level of abstraction beyond the 
PDP-8.  It attempts to make the notion of pages of code go away by 
creating instructions you didn't ask for when necessary.  This is often 
done at quite a big expense of efficiency, and in some cases also in 
point of fact doesn't work!

In essence, PAGE8 picks up where "links" leave off.  Consider a short 
subroutine named FOO that for foolish reasons is being attempted to be 
written too close to the end of the page to entirely fit.  PAGE8 will in 
fact generate the code there anyway!  The only requirement internally in 
PAGE8 is that the following *actual* code fit on the end of the page:

FOO,	0			/THIS IS THE HEADER THE USER SPECIFIED
	JMP I	(BAR)		/PAGE8-GENERATED LINK TO USER CODE!
FOOBAR,	JMP I	FOO		/PAGE8-GENERATED EXIT INSTRUCTION!

	PAGE			/PAGE8-CREATED ORIGIN TO NEXT PAGE AFTER
				/LITERALS ARE DUMPED

	BAR=	.		/PAGE8-GENERATED DEFINITION OF USER CODE CONTINUATION!

/	THE BODY OF THE USER CODE GOES HERE

	JMP I	FOO		/**** WRONG! **** THE USER WANTS TO
				/RETURN TO THE MAIN CALLER

What the last instruction actually generates is JMP I (FOOBAR) back to the
JMP I FOO on the previous page!  Also, I think you can imagine what
happens when you want to parse in-line arguments!  You get ISZ I (FOO)
instead of ISZ FOO. Statements of the form TAD I FOO generate additional
small subroutine calls to routines back on the original page that also
then have to fit because they can only work if actually on the same page
as FOO,.  Note that each line of code independently creates a kludge.
There isn't an attempt to make a small subroutine that includes TAD I FOO
and ISZ FOO on the same page as FOO, etc. 

For the same reason as why links in fact don't work, all of this naive 
coding helpout doesn't work:

On an -8 with extended memory beyond 4K, you cannot introduce arbitrary 
indirectness into an instruction.  Unless you limit this strictly to JMP 
and JMS, it then depends on something the assembler has no control over, 
namely the DF register.  When the code is written as the user intends, he 
owns control of the DF and how to use it.  Sophisticated subroutine 
handling may define the DF as belonging to the caller from another field, 
or perhaps where the caller's field is imputed, it actually refers to the 
field where the arguments passed in-line pertain to, or perhaps some 
totally other arbitrary user-defined meaning.  In any case, the assembler 
has no business in this process.  All of this toy code generation 
trickery depends strictly on the notion that the DF is the same as the IF 
of the code being manipulated!

Even in PAL8, links are as braindead.  Consider the following sloppiness:

	*200

	CDF	10
	TAD	400

When executed, the DF is set to 1 when you get to 00201.  Stupid PAL8 
links created an actual TAD I 377 where 00377 contains 0400.  OF course 
this doesn't work because it adds the contents of 10400, not 00400!

If you allow links because you are too lazy to write in -8 code, and want 
the assembler to write "almost -8" code for you, you are then obliged to 
check if all of the lazy links actually are JMP or JMS type strictly.  
You either have a ticking timebomb waiting to go off, or you are spending 
more time hand-checking against the accidental introduction of unwanted 
code than could have been better put to use merely by avoiding the link 
feature altogether.  It's a whole lot easier to use JMS I (FOO) where you 
need to.

BTW, there is a useful P?S/8 extension to literals that aids in 
efficiency in this area.  Perhaps there is an issue that the use of the 
pointer to a commonly used subroutine warrants it being called as JMS I 
[FOO] instead of JMS I (FOO).  It's likely that you can further classify 
calls as either "dominant" or "passive" in the sense that earlier in the 
source, it is likely determined that there are enough callers to warrant 
it, but somewhat later in the source, this information is more needed to 
be known than immediately apparent "locally" etc.  Within P?S/8 there is 
a feature for this known as a "dependent" literal.  In essence, the 
dominant callers decide whether there should be a global page zero type 
JMS I [FOO] as opposed to JMS I (FOO).  The dependent routines use 
neither!  Instead, they use the syntax JMS I \FOO/ which generates either 
type according to the following:  If the page-zero literal already 
exists, use it.  If not, then create a current-page reference.  Thus, if 
there is enough usage to demand a global literal, it gets used 
accordingly.  Else, the normal rules of current-page literals (which 
might be locally reused!) apply, etc.

So, I will continue to avoid like the plague assemblers with features 
like PAGE8, while I have the dependent literal on my wish list for a PAL8 
upgrade.  Without the feature, I compromise and hand-determine which way 
to setup all the calls, etc.  With today's good choice of powerful 
editors, this isn't really too much work fortunately, etc.

> then presumably you've weighed these advantages

I really couldn't care less about this part.  Here's a few reasons why:

1)	Making a distinction without a difference is pointless.  
So-called "modern" compiler writers should take heed of this!

2)	There are no such assemblers for the -8.  I specifically dismiss 
from the list any toy programs anyone has written over the years that are
useless to me because of the lack of the meat-and-potatoes features that 
I find even PAL8 a little too lean in, etc. (I have had to write 
non-portable code in P?S/8 PAL merely because it was the only way!  
Literally all other assemblers simply lacked the features to describe the 
program structure I was creating at the conceptual level.  In point of 
fact I had an obligation to make the program PAL8-compatible so it could 
be developed from OS/8, so I spent drudgery time hand-modifying working 
code to down-grade the source so PAL8 could actually assemble it 
correctly, etc.  If there is sufficient interest, I can elaborate on this.)

>in PDP8-land.  

If this is what's ailing you, then I understand.  But what the complaint 
is not what you said, but rather what is, is that there is *claimed* 
compatibility, but actually a promise not delivered.

Actually, there are two issues here.  MASM is a braindead assembler.  Who 
*wants* to be compatible with it!  Look at some PC code: most of it 
starts with an inefficient jump around data.  The reason is that the 
inefficiency in that initial jump is a sacrifice so that the other data 
doesn't fall prey to the same thing.  A more user-oriented data structure 
would put the data last perhaps, but to do so would make even more code 
inefficient.  (MASM always assumes jumps are a long-form.  When the code 
is fixed up, then a NOP occupies the wasted byte after the short jump, 
etc.  Thus, the lone wasted byte.  But at least the references to the 
rest of the data are forward this way, etc.)  In effect, MASM cannot 
create at the source level what you can hand-assemble and run from 
DEBUG.  However, there fortunately is no PDP-8 parallel to this nonsense.

The other issue is that Borland's product claims are exaggerated.  Only 
with effort is it true.  Thus, you got stung by claimed compatibility 
never fully delivered.  So, you have to either use MASM, or accept TASM 
as a different product with a different set of tradeoffs.  One could 
almost see this as a parallel to wanting to be compatible with PAL8 to 
avoid this sort of problem!  In any case, please separate the arguments 
of compatibility and fraudulent claims of compatibility, etc.

> When I got TASM the box said "100% compatible with
>of the basic sillinesses in MASM's design. 

I totally agree.  Fortunately, we don't have this dreadful a situation on 
the PDP-8!

> If I found (or wrote) an

You are seriously underestimating the situation here.  All of your 
programs are a proverbial drop in the bucket compared to what fills the 
PDP-8 pail.  And again, unless you offer some compelling reason to switch 
beyond different for difference's sake, what's the point?

>assembler?

IF that's truly true, then you are right.  However, why encourage 
mediocrity?  Perhaps if the right tools are available, someone will 
actually write non-trivial programs for the -8.  By having only mediocre 
tools, you are guaranteeing the results.

>  I wrote a lousy PDP-8 cross assembler when I was a freshman
>much for PAL/D), but so what?  

So what you are saying is that you had a toy project that included 
writing a toy assembler?  So what?  Indeed that's fine if that's the 
scope of it.  Besides, who would even want to deal with PAL/D which is 
the TSS8 dog assembler with no useful features anyway.  Lotsa people had 
input into PAL8 to correct a lot of the "sins of the past" such as 
PAL/D.  (I personally specified RELOC without which most of mine and 
others' work couldn't get done.  In fact, I'll go further: without RELOC 
I refuse to use PAL8!)

>I *like* to put dots on the beginning

Your personal preferences for the names of petty features aren't an issue 
to me beyond the reasons stated above.  I find it far more rewarding to 
adapt to a universal standard language than to bitch about cosmetics.  
More important to ensure the useful features that "matter" are present.

>John

cjl

---

From: [email-masked] (Charles Lasner)
Date: 9 May 1994 14:30:32 GMT

In article <[email-masked]>,

>will work correctly. It sure beats hand-assembling :-)

Totally agree with that.  Never was an issue.  John Wilson is really 
raising other issues answered elsewhere, etc.

>QuickC v2.5 on a PC. No changes needed.

It's good to know that it will run on a PC.  In case it gets to be a 
"real" assembler some day :-).

>PAL8. It's not like you're limited to one assembler for all programs...

No good.  Name this mythical assembler that has the functionality, but 
only achieved using incompatible syntax.  John is referring to incomplete 
projects that happen to have pet features that he finds useful while they 
leave out functionality found elsewhere, such as in PAL8.

cjl

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 9 May 1994 15:09:55 GMT

>From article <[email-masked]>,
by [email-masked] (Charles Lasner):
>>[email-masked] (John Wilson) writes...

We're not really trying to construct the longest USEnet thread in history,
are we?  This silly flamewar is rediculous!

1) Of course, full compatability with PAL 8 is desirable.  One of our
ultimate goals should be to create a source-level archive of all the
PDP-8 software we can get.  Source archives are far less fragile than
binary archives -- look what happened to that poor fellow who posted
in alt-folklore-computers when his data was converted from EBCDIC to
ASCII by someone who didn't know that it contained binary data as well
as text; odds are, he'll never recover the binary data!

Given a source archive and a decent portable cross assembler, you can
reconstruct the software you want and use it to rescue and rebuild a
system with nothing left functioning.  This can be particularly important
with diagnostics, where source listings would be particularly useful!

2) All I said was that I was in no hurry to produce a fully compatable
cross assembler.  Why the arguments about whether such compatability is
a worthy goal?

3) My assembler doesn't support conditional assembly, but other than that,
it appears to be source-level compatable with PAL.  The listing format
is mildly incompatable, it screams way too loud about off page references
(but assembles them correctly), and it is limited to a 32K memory model.
I'll probably put in conditionals someday.

					Doug Jones
					[email-masked]