Subject: This silly flamewar

From: [email-masked] (PDP11 Hacker .....)
Date: Mon, 9 May 1994 18:23:00 GMT

As I seem to be the start of this current stupid flamewar, maybe I should put a
few points in my defence....

Firstly, Lets look at the hardware. I've just rescued a PDP8e that was
otherwise going for scrap. This is my first real PDP8, my only other contact
with them being a DECmate 2 that I'd bought 1 week earlier and had done nothing
to. So, I get this machine home, sort out a problem with the PSU, get it to run
a simple program. I have no peripherals, no software. I know I need to remedy
this. So, I post to alt.sys.pdp8, and am flamed for not having a fully working
system. I've only had the machine for a week, and only worked on it at
weekends. Surely you don't have to have a full system, with every possible
option, to post here. Shouldn't we be encouraging the repair/rescue of the old
machines, however little they have on them. I know that if I was offered a
straight-8, no matter what the configuration, I'd jump at the chance...

Now lets look at the real flamewar - namely the assembler.
I understand that PAL-8 is the standard. I'd love to run PAL-8 on my system,
but until I get a disk and terminal up and running, I am unable to do so. My
first priority is to fix the remaining parts of my system. Now, I see this post
mentioning a C cross assembler. I think that this might be a way of building
little test programs to test the RK8 etc. Nothing more - as soon as I get the
machine working, I'll try and get some real software. So, I ask about it, and
am treated to a flame war. 

I've been computing long enough to know that compatability with the 'standard'
is not the only goal. What about all the CP/M systems with Z80's, whose
assemblers either used Ziolg mnemonics or Intel mnemonics. What about all the
FORTH assemblers. Useful work is done with all of these. In the HP saturn (the
calcuator CPU used in the 71, 18,19,28,48 etc series) world there are 2
completely different sets of mnemonics, and the assemblers for them have
totally different features. If you are building some HP code, you need an
HP-compatable assembler, sure. But the other mnemonics are somewhat more
logical, and some programmers prefer to use them. So What. Use whatever you
like

Much has been posted about the PAL-8 compatability, but I've yet to see one
example of the quirks that keep on being mentioned. What exactly are they? Why
do other assemblers break? Let's have some facts

-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] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 9 May 1994 19:35:46 GMT

>From article <[email-masked]>,
by [email-masked] (PDP11 Hacker .....):
> 
> Much has been posted about the PAL-8 compatability, but I've yet to
> see one example of the quirks that keep on being mentioned.

Quirks rarely center on the basic instructions (ADD, TAD, etc).

It's in the area of pseudo-ops that odd stuff happens.  If it was
just a matter of getting listings right (for example, odd handling
of XLIST, which toggles listing generation), it wouldn't be too bad,
but getting the following wrong can make a good program under one
assembler turn into pure nonsense on another:

	ENPUNCH -- turn on binary (object file) output
	NOPUNCH -- turn off binary output
			Do these nest or does the first ENPUNCH
			after a sequence of NOPUNCHES undo the
			effects of all of them.

	I -- indirect (as in TAD I WHIZZO)
	Z -- page zero (as in TAD Z WHIZZO)
			Are I and Z just constants?  If not, what
			special semantics do they have?

	IFDEF
	IFNDEF
	IFZERO
	IFNZRO -- conditional assembly.
			How do conditional assembly directives nest.
			If a closing bracket is found in a comment,
			is it ignored or does it close the conditional.

	EXPUNGE -- clear the symbol table of all but pseudooperations
	FIXTAB -- mark all symbols as permanent
	FIXMRI -- define a new memory reference instruction mnemonic
			How do these interact?
			How do these interact?

	RELOC -- assemble code into one location that will run in another.
			There are a multitude of ways to get this wrong,
			particularly when it comes to the effects of
			consecutive RELOC pseudoops -- is the effect
			cumulative?  How does it accumulate?

Most of these quirks are of no importance at all for the purposes you and
I envision for the kind of cross assembler I wrote -- downloading simple
little test programs rarely involves any of these!  On the other hand,
after I get around to getting my RX01 drives working, I'll be looking for
an operating system.  If I have to assemble something like OS8, it'll
likely require full compatability with the above.

I have full source listings of a number of 1960's vintage paper-tape
tools for the -8, and I'd like to scan them into machine-readable form
and then try assembling them (this is practical!  We tried a test scan
of a few pages of the old 4K Fortran system, and Kurzweil Reading Machine
could indeed read the smudgy old line-printer characters).  Again, a
fully compatable assembler is what I need for such a job.

					Doug Jones
					[email-masked]

---

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

In article <[email-masked]>,
>Quirks rarely center on the basic instructions (ADD, TAD, etc).

Oh yeah?  Try assembling

	*TAD	.

	TAD	TAD	TAD	.

And not as ridiculous as it sounds.  Handlers have stuff like:

	TAD	(TAD I	FOO)
	DCA	.+1
	.-.

>assembler turn into pure nonsense on another:

If XLIST turns off the listing, then it assembles anyway.  If multiple 
statements are on the line, then the first statement can be XLIST and 
prevent seeing the listing line, but if the statements before XLIST get 
the line listed out, the XLIST applies to the next line.  (And you get to 
see the "XLIST" itself that way!

Additionally, XLIST is a flip-flop initially on.  Further, it takes 
evaluated arguments where 1=turn it off and 0=turn it on.  Some of my 
sources start with:

	XLIST	OFF

	IFNDEF	OFF	<OFF=	1>
	IFNDEF	ON	<ON=	0>

	XLIST	ON

Note that even XLIST 0 doesn't get listed unless there are multiple 
statements on the line and subsequent statements beyond the XLIST want 
the output to show.  This is the symmettrical opposite of the XLIST 1 
situation, etc.

>			after a sequence of NOPUNCHES undo the
The correct way is independently, not nested.

>			special semantics do they have?

NO!!!!!!!  They are pseudo-ops that modify the parse scan.  Once I has 
been scanned, the rest of the scan is attempting to find an argument to 
the prevailing MRI operation that has been placed in effect earlier.  
Were I just another symbol, then they would be affected by this, but 
rather they just mean that the indirect (or removal of the current page 
bit in the case of Z) bit is to be OR'ed into the instruction after the 
generation is resolved.  Also, if you find another MRI as part of the 
operation, you have to push down the state of I as well as all else, so 
you can then resolve the MRI argument of that MRI which in turn could 
have its own I.

However, if an MRI scan isn't in effect, then I does have the value of 
0400 in -8 mode and 0020 in LINC mode.

>			is it ignored or does it close the conditional.

This has been a hot issue for years.  Clearly conditionals nest.  But 
what abouts comments in the wake of a failing conditional being flushed?
True compatibility demands that the comments be scanned!  I would like to 
see an option to make comments be ignored.  The issue is that if a 
conditional fails, what you do is attempt to find ">" and ignore (flush) 
all input until you find it.  However, should you find "<" along the way, 
you increment the count of ">" you must find.  Getting to the end of the 
file input is a fatal "phase" error during a flush.

But as currently implemented, there is no check for whether the ">" and 
"<" are within a comment.  Most of us either avoid brackets in comments, 
or perversely make them "match"!  If you add the feature to totally avoid 
brackets in a comment field until local end-of-line to end the comment, 
some existing programs will break!  In any case, should a conditional 
succeed, finding the ">" is ignored in terms of syntax error.  The best 
solution is to do it either PAL8 way or with an option switch to the 
assembly.

>	FIXMRI -- define a new memory reference instruction mnemonic

EXPUNGE is operational anytime during pass 1 only.  Same for FIXTAB.  
FIXMRI can always work.  Additionally, FIXMRI can create indirect-forced 
MRI's such as:

	FIXMRI CALL=	JMS I	0

This allows such niceties as:

	CALL	[FOO]

and

FOO,	.-.

	EXIT	FOO

Where EXIT is defined with FIXMRI as JMP I  0.

>			cumulative?  How does it accumulate?

RELOC is cumulative.  RELOC with no argument turns off the feature.  
Assuming a separate binary and source location counter, RELOC calculates 
the difference between the argument and the current source location 
counter and adds that difference to the binary location counter.  Thus, 
consider the following code:

	*200

	RELOC	7600

This should be familiar to anyone who ever looked at an OS/8 system 
handler.  The source location counter is now 7600, yet the binary is 
still at 0200.  This is because the difference of 7400 was added to the 
binary value so when it was changed to 7600, it was set back to 0200.  
However, it could have been different from the source location counter at 
the time due to a *prior* RELOC!  (In this simple example it doesn't apply.)

>likely require full compatability with the above.

You bet!

>fully compatable assembler is what I need for such a job.

Is that the paper-tape 4K fortran, or the DM one?

cjl

---

From: [email-masked] ("Stephen Walters")
Date: Tue, 10 May 1994 00:23:19 GMT

I have a stack of tapes Magnetic and paper which came the 8. The machine 
originally came from the National Physical Laboratory...and they had a 
rather extensive software library...

I also have an Intersil machine which has the appearance of a miniture 8, 
switches and all. Even has battery backed RAM!

[email-masked]

---

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

>From article <[email-masked]>,

> switches and all. Even has battery backed RAM!

Great!  That makes two surviving Intersil machines.  The other one I know
of is serial number 1, won by a visitor at the trade show where it was
first exhibited.  It ran DEC's paper-tape 4K FOCAL, obtained by the owner
from a PDP-8/S owner, but I know little more about it.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 10 May 1994 16:21:13 GMT

>From article <[email-masked]>,
by [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879):
> 
> Great!  That makes two surviving Intersil machines.

Great!  I goofed in that last posting.  Please ignore it!  I spaced out
and confused Intersil with another maker
 
 					Doug Jones
 					[email-masked]

---

From: [email-masked] (Douglas W. Jones,201H MLH,3193350740,3193382879)
Date: 10 May 1994 21:46:50 GMT

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

> Oh yeah?  Try assembling ...

Here's a current example of the state of affairs with my little toy
cross assembler.  It illustrates some of the little nasties you've
posted, and I should note that your posting prompted me to fix a few
bugs and add support for FIXMRI.

   1 01000 0602 * TAD I .+2              / a bug, but is it worth fixing?
   2 01001 1377         TAD (TAD I FOO)  / I don't doubt the use of this!
   3            FIXMRI  CALL=   JMS I 0
   4            FIXMRI  RETURN= JMP I 0  / This is indeed useful.
   5 01002 4577         CALL    [FOO]
   6 01003 0000 FOO,    .-.
   7 01004 5603         RETURN  FOO
   8 01177 1603 $
     00177 1003

Now, some questions.  What should the following do?  And, are these funny
cases worth worrying about?

        TAD     AND     5
        TAD     (AND    [15])

I'm pretty sure that existing DEC versions of PAL are likely to mess up
a bit on some simple variants of the latter:

        TAD     (AND    [15+1]-1)+3

                                        Doug Jones
                                        [email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 11 May 1994 15:13:26 GMT

In article <[email-masked]>,
>from a PDP-8/S owner, but I know little more about it.

No, this is an Intercept I.  I have one.  I also have a PCM-12.  (There 
was a PCM-12A that fixed something, but I don't have info as to what.)

These machines are buss compatible.  Intersil was proud of the fact that 
you could remove modules while it was running.  The Intercept stuff that 
I have is:

3 4K CMOS battery-backed memory modules

TTY: interface (supports 110 baud TTY: and reader run on an ASR-33 modified 
according to DEC standards)

RX-type interface to DSD-210 dual RX01-compatible drive (that can format!)

Extended memory controller.

The PCM-12 has 4K (not CMOS) and a similar TTY: interface.  It is a more 
"packaged" machine and likely can support all of the Intercept stuff to 
make one 16K machine with dual floppy.  The Intercept has limited 
internal space, but this one has the buss expander which has been 
rack-mounted, etc.

Unlike DEC's VT-78, these 6100-based systems run at full speed (4.0 
MHz).  The front panel is implemented in CP memory using memory-mapped 
I/O (such as AC -> LED's is implemented as storing into CP 0000 with a 
DCA instruction.  I imagine you can step the LED as a register by using 
ISZ 100.).  The rate of panel update is controllable by a clock interrupt 
rate potentiometer which can be disabled for maximum throughput without 
panel update.  (Remember, the original intention of CP memory was for a 
Control Panel!)  Full front panel function switches are provided, just 
like on an -8/e, but all implemented in CP software, etc.  A standard RX 
boot is built-in, etc.

On paper at least, PCM and Intersil did offer a large complement of 
peripherals, generally mimicking DEC's designs of common program transfer 
peripherals of the Omnibus.

cjl

---

From: [email-masked] (Charles Lasner)
Date: 11 May 1994 22:07:49 GMT

In article <[email-masked]>,

>   4            FIXMRI  RETURN= JMP I 0  / This is indeed useful.

Well, we'll see about that!

OK, I took Doug's code and passed it to both PAL8 and P?S/8 PAL.  Here 
are both listings.  Note that page breaks are replaced with "<FF>" 
instead of the actual page form-feeds, etc.  (In both assemblers, the 
output uses LF characters to space the paper down on the console, and 
uses real FF chars on the LPT:.  Neither was useful for posting, etc.)

First PAL8:

/       TEST OF SOME OF DOUG'S QUIRKY EX  PAL8-VB0  11-MAY-94 PAGE 1

              /       TEST OF SOME OF DOUG'S QUIRKY EXAMPLES

        1602          * TAD I .+2                     /HE SAYS THIS IS A BUG!

001602  1377          TAD     (TAD I  FOO)            /HE KNOWS THIS IS USEFUL

              /       SOME FIXMRI'S WITH THE I BIT SET.

        4400          FIXMRI  CALL=   JMS I   0       /DEFINE CALL MRI

        5400          FIXMRI  RETURN= JMP I   0       /DEFINE RETURN MRI

001603  4577          CALL    [FOO]                   /CALL A SUBROUTINE
                                                      /WITHOUT USING JMS

001604  0000  FOO,    .-.                             /SUBROUTINE

001605  5604          RETURN  FOO                     /RETURN TO CALLER

IC
001606  1000          TAD     AND     5               /LET'S SEE

001607  1376          TAD     (AND    [15])           /LET'S SEE

LG
001610  1774'         TAD     (AND    [15+1]-1)+3     /LET'S SEE

001774  2000
001775  0174
001776  0176
001777  1604
                      $                               /END OF ASM
000175  0016
000176  0015
000177  1604
<FF>
/       TEST OF SOME OF DOUG'S QUIRKY EX  PAL8-VB0  14-APR-90 PAGE 2

CALL   4400      
FOO    1604      
RETURN 5400      
<FF>

ERRORS DETECTED: 2
LINKS GENERATED: 1

Now P?S/8 PAL:

/     TEST OF SOME OF DOUG'S QUIRKY EXAMPLES  P?S PAL V08S    WED  11-MAY-94  PAGE 1

              /       TEST OF SOME OF DOUG'S QUIRKY EXAMPLES

       *1602          * TAD I .+2                     /HE SAYS THIS IS A BUG!

001602  1377          TAD     (TAD I  FOO)            /HE KNOWS THIS IS USEFUL

              /       SOME FIXMRI'S WITH THE I BIT SET.

        4400          FIXMRI  CALL=   JMS I   0       /DEFINE CALL MRI

        5400          FIXMRI  RETURN= JMP I   0       /DEFINE RETURN MRI

001603  4577          CALL    [FOO]                   /CALL A SUBROUTINE
                                                      /WITHOUT USING JMS

001604  0000  FOO,    .-.                             /SUBROUTINE

001605  5604          RETURN  FOO                     /RETURN TO CALLER

001606  1005          TAD     AND     5               /LET'S SEE

001607  1376          TAD     (AND    [15])           /LET'S SEE

LG 
001610  1774'         TAD     (AND    [15+1]-1)+3     /LET'S SEE

                      $                               /END OF ASM
       *1774 
001774  2000 
001775  0174 
001776  0176 
001777  1604 
       *0175 
000175  0016 
000176  0015 
000177  1604 
<FF>
/     TEST OF SOME OF DOUG'S QUIRKY EXAMPLES  P?S PAL V08S    WED  11-MAY-94  PAGE S-1
USER SYMBOL TABLE LISTING

CALL  =4400M
FOO    1604 
RETURN=5400M
<FF>
/     TEST OF SOME OF DOUG'S QUIRKY EXAMPLES  P?S PAL V08S    WED  11-MAY-94  PAGE S-2
ASSEMBLY STATISTICS

1 ERROR  DETECTED 

1 LINK  GENERATED

5K MEMORY UTILIZED 

NO FILES CREATED

3 SYMBOLS

Some comments on Doug's tests, and differences between the assemblers 
themselves:

1)	Both assemblers were set to generate links, but flag them as 
errors.  In PAL8, links are unavoidable, but considering them as errors 
is optional.  In P?S/8 PAL, links can be prevented altogether, allowed 
but flagged as errors, or allowed without being considered errors.

2)	In PAL8 you can't get a listing without a symbol table, although 
you can get a symbol table only by asking for the listing to be deleted.  
In P?S/8 PAL, a symbol table is optional as is the listing.  Thus, PAL8 
was invoked without deleting the listing.  P?S/8 PAL was invoked with 
both listing and symbol table options set.

3)	No binary files were asked for in either case, so none were 
created.  This doesn't change the output anyway (other than the P?S/8 
statistics page).

4)	PAL8 couldn't handle the double MRI case.  P?S/8 PAL did handle 
it correctly; the first MRI used the results of the second MRI's scan as 
its argument.  Since P?S/8 PAL pushes down its context for each and every 
MRI encountered, this isn't surprising.  (Both assemblers push the 
context down during a literal scan.)  Since PAL8 doesn't give the 
character code of the Illegal Character it was complaining about (P?S/8 
PAL does!) we can only guess as to exactly where the scan was complained 
about.  (P?S/8 PAL IC messages give the ASCII code of the offending 
character as well as placing it within the assembly, etc.)

5)	P?S/8 PAL has some cosmetic advantages over PAL8.  There are 
sub-titles on all assembler-generated output pages.  The header line 
includes more of the first-line comment to make a wider output line.  The 
header line also includes the day of the week; useful when thumbing 
through a stack of listings of recent assemblies!

	The symbol table printout indicates the symbol type as well as 
the value.  Additionally, if the symbol is defined by an equate, an "=" 
is indicated.  MRI-type symbols have an "M" suffix.  (Note: it is 
possible to ask for a complete symbol table dump, which includes 
permanent symbols.  In that case, directives such as OCTAL are listed 
where the value is the internal address within the assembler and a "D" is 
the suffix.)

	There are a lot of hacks on the statistics page.  PAL8 cops out 
and puts the item count last on the line after ":".  P?S/8 PAL makes the 
operative word singular if exactly one, and puts out "NO" if the count is 
zero.  Additionally, the reported memory size is the minimum size rounded 
up to the nearest 1K that the assembler could have used to assemble this 
program without overflowing the table.  In this particular case, the 
value is "5K" because the assembler was invoked without the "stingy 
buffer" option which would make it assemble a whole lot slower but saves 
memory.  In that case, the report would indicate that 4K would be 
required, etc.  Also, the count of fixed binary files created is reported, 
while PAL8 never tells you if binary happened (you have to know from the 
command line, not the listing).

Whenever an origin is generated (whether by user "*" commands or 
auto-generated by a literal dump or after a field setting if enabled, 
etc.) P?S/8 PAL shows it preceded by an "*".  PAL8 only shows the octal 
value on a "*"-generated one, and doesn't output the auto-generated ones 
at all.  Thus, in PAL8 you cannot tell if the auto-origin after field 
setting is enabled from the listing, only the command.  (In both 
assemblers the auto-origin is an option, etc.)

A logistic complaint about PAL8 (solved in P?S/8 PAL):  When you are 
first preparing an assembler source, it's likely that there are a few 
dozen globally referenced symbols you haven't gotten around to editing in 
yet.  There are probably hundreds of references to them as well.

In PAL8, if you attempt an assembly, you thus wind up with hundreds of 
errors of the form "US FOOBAR+3" which means that you are told *where* 
(relative to a recent label) an undefined symbol is being attempted, 
without identifying *what* that symbol actually is!  Since you are 
inundated with these messages, you can either write some of them down and 
then do an edit and yet another series of two-pass assemblies (the 
messages only come in pass two; pass one is "silent".) until you get it 
down to a dull roar, or instead get a very deficient listing that is even 
more wasteful, and then hand-track all of the references to produce an 
edit/change that involves adding a few dozen lines (mostly on page zero 
typically).  Either way, you are doing a whole lot of assembly over a 
relatively small matter, etc.

The P?S/8 PAL solution is to use a feature that originates in the 
original PAL III paper-tape assembler.  At the end of pass one (P?S/8 PAL 
can specify a one-pass assembly) there is a summary printout of all 
symbols still undefined.  The octal value of the symbol is printed out; 
in this case, this value is the address where the earliest encounter with 
the then (and now-still !) undefined symbol was found.

Thus, instead of wasteful second-passes, listings, additional two-pass 
assemblies, etc., P?S/8 PAL produces a small report where each undefined 
symbol takes one line!  (This can be directed at the LPT: if desired.)

Additionally, should a second-pass assembly cough up some Undefined 
Symbol errors, the messages look like:

US BARFOO AT FOOBAR+3 (0203)

Thus, the info is the same as PAL8 in the relative-to-recent-symbol 
sense, but also is given in absolute form as well.  But more importantly, 
the undefined symbol is *named* !

In any case, looking at Doug's assembler output, I would say he still has 
a little ways to go to match the -8-written ones.

cjl