[cctalk] Re: HCF [was: System 360 question]

2024-11-04 Thread Paul Koning via cctalk



> On Nov 4, 2024, at 12:15 PM, Mychaela Falconia  wrote:
> 
> Paul Koning wrote:
> 
>> On the "one word clear", I missed a detail.  I pointed out you get to
>> initialize the registers.  You can also initiate one memory word.  In other
>> words: choose two words in memory, and registers contents, such that
>> execution will give you a memory full of zeroes and a halted machine.
> 
> OK, *now* the problem has a clear solution:
> 
> 1) Write 00 into memory word 015720;
> 2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM;
> 3) Clear R0;
> 4) Jump to the last word of RAM where you wrote the 015720 instruction.
> 
> This solution does require that the system RAM be of certain minimum
> size.  Assuming power-of-2 sizes only, the machine must have at least
> 8 KiB of RAM, otherwise location 015720 does not exist.  What was the
> smallest RAM configuration on PDP-11?

Yes, that's the correct answer.

4 kW is the smallest PDP-11 memory I know of, though I don't have direct 
exposure to the T-11.

paul



[cctalk] Re: HCF [was: System 360 question]

2024-11-04 Thread Mychaela Falconia via cctalk
Paul Koning wrote:

> On the "one word clear", I missed a detail.  I pointed out you get to
> initialize the registers.  You can also initiate one memory word.  In other
> words: choose two words in memory, and registers contents, such that
> execution will give you a memory full of zeroes and a halted machine.

OK, *now* the problem has a clear solution:

1) Write 00 into memory word 015720;
2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM;
3) Clear R0;
4) Jump to the last word of RAM where you wrote the 015720 instruction.

This solution does require that the system RAM be of certain minimum
size.  Assuming power-of-2 sizes only, the machine must have at least
8 KiB of RAM, otherwise location 015720 does not exist.  What was the
smallest RAM configuration on PDP-11?

M~


[cctalk] Re: HCF [was: System 360 question]

2024-11-04 Thread Paul Koning via cctalk



> On Nov 4, 2024, at 12:34 AM, ben via cctalk  wrote:
> 
> On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote:
>> On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia via cctalk
>>  wrote:
>>> 
>>> Paul Koning wrote:
>>> 
 1. Show a one-word PDP-11 program that writes all of memory, in reverse 
 order.
>>> 
>>> MOV -(PC),-(PC)
>> Does that work on all models of PDP11?
>> I had an idea that (as in C) the order of the decrements and reads was
>> not specified by the instruction set definition and that on some
>> machines (the 11/45?) it doubly decrements PC before reading or
>> storing.
>> -tony
> 
> Where there any user instructions between models that gave strange behavior 
> on the wrong machine?

Yes, and they are documented in the PDP-11 architecture manual, in an appendix. 
 But it cases that are machine dependent are more exotic, things like mixing a 
register reference with an auto inc/dec of the same register.  The magic move 
will work on any of them.

On the "one word clear", I missed a detail.  I pointed out you get to 
initialize the registers.  You can also initiate one memory word.  In other 
words: choose two words in memory, and registers contents, such that execution 
will give you a memory full of zeroes and a halted machine.

paul

[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Mychaela Falconia via cctalk
Tony Duell wrote:

[Context: MOV -(PC),-(PC) ]
> Does that work on all models of PDP11?

No idea, I just know that it worked on Soviet 1801VM1, which is where
I learned it.

Meanwhile, I am still struggling with the second part of Paul's
original challenge:

> 2. Show a one-word PDP-11 program that clears all of memory,
> in forward order, halting on completion.

The problem statement says that the trick must *clear* all of memory,
which I read as making it all zeros, rather than some other clobber
pattern.  The "halting on completion" part makes sense: 00 is the
opcode for HALT, hence if there is a magic instruction running in a
loop at the end of memory that writes zeros moving forward, once this
write of zeros hits the executing code, halt will occur.

But I am still not able to come up with a single-word PDP-11
instruction that does these two functions simultaneously:
(1) decrements PC so that the instruction keeps re-executing, and
(2) writes zeros moving forward.  Paul gave this hint:

> Hint: you get to pick the initial values of the registers.

I can easily think of something like this:

MOV -(PC),(R0)+

But this one won't satisfy the requirement of writing zeros: it does a
forward clobber, but writes 014720 (the opcode for this instruction)
instead of zeros.  I thought of refining it like this:

BIC -(PC),(R0)+

This one gets a bit closer in that it will clear _some_ bits to zero
in every memory word, but still, it is not a write of all zeros.

Then I thought about the XOR instruction that appears in later PDP-11
models; something like:

XOR R0,-(PC)

If R0 is preset to 074047 (the opcode), the instruction will overwrite
itself with 0 word (HALT), and then the halt will happen.  But that's
only one word, not clearing all of memory, and of course it would be
even simpler with:

CLR -(PC)

Why is there a -(PC) operand in each of my attempts above?  Because I
don't see another way to make the instruction keep re-executing.  If
it weren't for this re-execution requirement, the solution would be as
simple as

CLR (R0)+

but of course that one will result in the CPU executing garbage
following this instruction after clearing just one memory word - not
interesting...

If PDP-11 had 3-operand instructions like VAXen do, we could do an
instruction that has -(PC) as one operand, a preset register as the
second operand to the addition or XOR or whatever, and something like
(R0)+ as the destination operand - but we are talking about PDP-11
here, not VAX, and the requirement is for a single-word instruction.

Thus I do not see how a single PDP-11 instruction can accomplish what
is asked here - unless I am misinterpreting the problem statement...

M~


[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread ben via cctalk

On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote:

On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia via cctalk
 wrote:


Paul Koning wrote:


1. Show a one-word PDP-11 program that writes all of memory, in reverse order.


MOV -(PC),-(PC)


Does that work on all models of PDP11?

I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.

-tony


Where there any user instructions between models that gave strange 
behavior on the wrong machine?




[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Tony Duell via cctalk
On Mon, Nov 4, 2024 at 4:06 AM Mychaela Falconia via cctalk
 wrote:
>
> Paul Koning wrote:
>
> > 1. Show a one-word PDP-11 program that writes all of memory, in reverse 
> > order.
>
> MOV -(PC),-(PC)

Does that work on all models of PDP11?

I had an idea that (as in C) the order of the decrements and reads was
not specified by the instruction set definition and that on some
machines (the 11/45?) it doubly decrements PC before reading or
storing.

-tony


[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Cameron Kaiser via cctalk


>>> 2. Show a one-word PDP-11 program that clears all of memory,
>>> in forward order, halting on completion.
>>
>> This one I am struggling with - it's been too many decades since I did
>> any PDP-11 assembly...
>
> Hint: you get to pick the initial values of the registers.

Can we pick the initial contents of memory? ;)

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * [email protected]
-- Go Computer Now! -- Sphere Corporation -



[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Jon Elson via cctalk

On 11/3/24 15:39, Paul Koning via cctalk wrote:


Yes, but you don't need such an architecture for this.  A PDP-11 can do it 
also.  I once assigned that as a a pair of homework questions in an assembly 
language programming course:

1. Show a one-word PDP-11 program that writes all of memory, in reverse order.
2. Show a one-word PDP-11 program that clears all of memory, in forward order, 
halting on completion.


Yes, I did something like this when we got our first VAX 11/780.

Jon



[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Mychaela Falconia via cctalk
Paul Koning wrote:

> 1. Show a one-word PDP-11 program that writes all of memory, in reverse order.

MOV -(PC),-(PC)

I remember this one from late-Soviet/early-Russian BK0010 hacker clubs...
BK0010 was a "home computer" built around 1801VM1 microprocessor, a
Soviet implementation of basic PDP-11 instruction set.  No idea exactly
which DEC model it corresponds to, if any.

> 2. Show a one-word PDP-11 program that clears all of memory,
> in forward order, halting on completion.

This one I am struggling with - it's been too many decades since I did
any PDP-11 assembly...

M~


[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Paul Koning via cctalk



> On Nov 3, 2024, at 4:59 PM, Mychaela Falconia  wrote:
> 
> Paul Koning wrote:
> 
>> 1. Show a one-word PDP-11 program that writes all of memory, in reverse 
>> order.
> 
> MOV -(PC),-(PC)
> 
> I remember this one from late-Soviet/early-Russian BK0010 hacker clubs...
> BK0010 was a "home computer" built around 1801VM1 microprocessor, a
> Soviet implementation of basic PDP-11 instruction set.  No idea exactly
> which DEC model it corresponds to, if any.
> 
>> 2. Show a one-word PDP-11 program that clears all of memory,
>> in forward order, halting on completion.
> 
> This one I am struggling with - it's been too many decades since I did
> any PDP-11 assembly...

Hint: you get to pick the initial values of the registers.

paul



[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Chuck Guzis via cctalk
On 11/3/24 12:56, paul.kimpel--- via cctalk wrote:
> CAREY SCHUG wrote:

>> 2. remember that record mark? if you ever executed an instruction with a 
>> record mark in
>> the address, you got a MAR check red light, a hard reset was required to 
>> escape.  probably
>> if in the op code also.  And some hard stop for any invalid op code, but 
>> these may have
>> been in the category below.
> 
> Shouldn't these be considered good error-trapping features and not in the 
> same league as HCF?  An RM had the 8 and 2  bits set, so it wasn't a valid 
> decimal digit, and couldn't be used in an address. An RM in the Q field of an 
> immediate instruction was okay, though.

On card-oriented CADETs, there were a few alternatives to the nuisance
of having to multipunch a record or group mark on an 026.  I seem to
recall that a period read numerically translated to 8-2-1 and worked
just as well.

Among other shortcomings of the 1620, there was no way to test for
numeric blank (8-4).  You just had to know that it was there.  There
were several such bugaboos, with which Dijkstra had issues.  Still, the
1620 was capable of doing real work--and its 1710 relative was capable
of industrial process control application.

--Chuck


[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Paul Koning via cctalk



> On Nov 3, 2024, at 3:55 PM, Chuck Guzis via cctalk  
> wrote:
> 
> On 11/3/24 10:06, David Wise via cctalk wrote:
>> 1620 owner here.
>> 
>> Sure there are ways to cause a CHECK STOP, and one-instruction infinite 
>> loops, including the IBM-sanctioned one you describe below - which everyone 
>> used all day to clobber core - but that's all they are, they don't damage 
>> hardware.
>> 
>> You can make an infinite loop that is sort of less than one instruction.  
>> It's an instruction with a self-referencing indirect address.  (Only applies 
>> to Model II, and Model I machines with the Indirect Addressing feature 
>> installed, like mine.)  When it tries to fetch the indirect operand, it 
>> loops in the Fetch cycle without ever reaching Execute stage.  While that 
>> sounds like a core hammer, it is still less than 30% duty cycle on any one 
>> address.  Also remember the core stack has air blowing through it nonstop.
> 
> Sure, there was more than one way to, say, clear memory on a 1620 with a
> single instruction--and it was common knowledge.   One could use a
> transmit record or transmit field instruction that not only over-wrote
> general memory, but also clobbered the instruction itself.
> 
> Such is the glory of variable field/record length architectures.

Yes, but you don't need such an architecture for this.  A PDP-11 can do it 
also.  I once assigned that as a a pair of homework questions in an assembly 
language programming course:

1. Show a one-word PDP-11 program that writes all of memory, in reverse order.
2. Show a one-word PDP-11 program that clears all of memory, in forward order, 
halting on completion.

paul

[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread paul.kimpel--- via cctalk
CAREY SCHUG wrote:
> I'm going to suggest that the 1620 had the most HCF instructions of any 
> commercially
> produced computer, ever.  And the most intentionally used on a daily basis.


> 1. you could press "insert" on the typewriter and enter a program starting at
> location zero which was executed when you hit return.  If you wanted to clear 
> memory, you
> typed in 12 digits "31900010" (transmit record) which meant copy the
> character at location 9 to location 10, then 10 to 11, etc until it found the 
> special
> character "record mark", which it would never find as you typed in a zero at 
> the
> starting address.  watch the address lights till it looped and hit reset.

Note that, as written, your instruction doesn't clear memory, it shifts memory 
to the left by one digit every complete cycle through memory, because the 
destination address is lower than the source address. What you need to do a 
"forward smear," where the source address is lower than the destination 
address, so that the destination digits become source digits as the addresses 
increase, e.g., 3132. 

That would only work on a 1620 Model 1, however. It wouldn't work on a Model 2. 
Both models fetched two digits from memory at a time, but for many instructions 
(including TR and TF) the Model 2 would stash the digit at the odd address and 
use it during the odd-address fetch cycle, saving a redundant fetch from the 
same digit pair in memory. Therefore, the source and destination addresses had 
to differ by at least 2 -- this will work on the Model 2: 3142.

But nobody bothered with that on the Model 2, because it had a hardware memory 
clear mechanism. Simultaneously pressing MODIFY (which wasn't present on the 
Model 1) and CHECK RESET on the console would turn on the CLR MEM control gate. 
Then pressing START would clear all of memory once and halt.


> 2. remember that record mark? if you ever executed an instruction with a 
> record mark in
> the address, you got a MAR check red light, a hard reset was required to 
> escape.  probably
> if in the op code also.  And some hard stop for any invalid op code, but 
> these may have
> been in the category below.

Shouldn't these be considered good error-trapping features and not in the same 
league as HCF?  An RM had the 8 and 2  bits set, so it wasn't a valid decimal 
digit, and couldn't be used in an address. An RM in the Q field of an immediate 
instruction was okay, though.

> 3. there were other errors, but you could press start to continue and there 
> was a toggle
> switch to ignore at least some of them, like a parity error in memory.

You could press START to continue after a memory parity error or an I/O parity 
error, but not after a MAR CHECK.

The PROGRAM/STOP toggle switches (there were four of them, for DISK, MEMORY, 
I/O, and arithmetic OVERFLOW) did not cause the errors to be ignored, they just 
controlled whether the CPU halted when exceptions occurred. In all cases, 
internal flags (termed "indicators") were set, which could be interrogated by 
the BI and BNI instructions. The MEMORY switch had no effect on a MAR CHECK -- 
the CPU always did a hard stop on those and required a RESET.



Paul


[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread Chuck Guzis via cctalk
On 11/3/24 10:06, David Wise via cctalk wrote:
> 1620 owner here.
> 
> Sure there are ways to cause a CHECK STOP, and one-instruction infinite 
> loops, including the IBM-sanctioned one you describe below - which everyone 
> used all day to clobber core - but that's all they are, they don't damage 
> hardware.
> 
> You can make an infinite loop that is sort of less than one instruction.  
> It's an instruction with a self-referencing indirect address.  (Only applies 
> to Model II, and Model I machines with the Indirect Addressing feature 
> installed, like mine.)  When it tries to fetch the indirect operand, it loops 
> in the Fetch cycle without ever reaching Execute stage.  While that sounds 
> like a core hammer, it is still less than 30% duty cycle on any one address.  
> Also remember the core stack has air blowing through it nonstop.

Sure, there was more than one way to, say, clear memory on a 1620 with a
single instruction--and it was common knowledge.   One could use a
transmit record or transmit field instruction that not only over-wrote
general memory, but also clobbered the instruction itself.

Such is the glory of variable field/record length architectures.

--Chuck




[cctalk] Re: HCF [was: System 360 question]

2024-11-03 Thread David Wise via cctalk
1620 owner here.

Sure there are ways to cause a CHECK STOP, and one-instruction infinite loops, 
including the IBM-sanctioned one you describe below - which everyone used all 
day to clobber core - but that's all they are, they don't damage hardware.

You can make an infinite loop that is sort of less than one instruction.  It's 
an instruction with a self-referencing indirect address.  (Only applies to 
Model II, and Model I machines with the Indirect Addressing feature installed, 
like mine.)  When it tries to fetch the indirect operand, it loops in the Fetch 
cycle without ever reaching Execute stage.  While that sounds like a core 
hammer, it is still less than 30% duty cycle on any one address.  Also remember 
the core stack has air blowing through it nonstop.

There is a setup on the Customer Engineer switch panel (INC plus BYP) that will 
hammer a single address, but I don't remember a warning.  The only damage risk 
is if one or more of your decode switch transistors are failing to ground their 
A/B/C/D drive line, or you have an open X or Y line.  In that case there's an 
inductive voltage spike that will stress all the other D-S transistors.  The CE 
Reference Manual warns against clocking in this state for more than a couple 
seconds.

Dave Wise in Hillsboro Oregon

The entire first production run (Suffix B) was paper tape only.  Card support 
was added at Suffix C.
The core memory array is 3D with two-level selection.  The main array select 
lines are X and Y.  They are driven by 10x10 matrix switches which are in turn 
driven by 10 decode switches each on A, B, C, and D.  A and B select X, C and D 
select Y.  This is slow but it minimizes the number of costly high-performance 
transistors.  The 1401 is the same.


From: CAREY SCHUG via cctalk 
Sent: Sunday, November 3, 2024 7:13 AM
To: General Discussion: On-Topic and Off-Topic Posts 
Cc: CAREY SCHUG 
Subject: [cctalk] HCF [was: System 360 question]

I'm going to suggest that the 1620 had the most HCF instructions of any 
commercially produced computer, ever.  And the most intentionally used on a 
daily basis.  It is a memory-to-memory computer with no actual registers (the 
model II had index registers, but they were in memory).  Few machines had 
disks, and fewer had tape (magnetic or paper), so they were almost always run 
from tabulating cards.  I always started my session with the clear memory 
command below, and maybe several more times during my scheduled hour.

1. you could press "insert" on the typewriter and enter a program starting at 
location zero which was executed when you hit return.  If you wanted to clear 
memory, you typed in 12 digits "31900010" (transmit record) which meant 
copy the character at location 9 to location 10, then 10 to 11, etc until it 
found the special character "record mark", which it would never find as you 
typed in a zero at the starting address.  watch the address lights till it 
looped and hit reset.  Or "TF 9,8" (transmit field) which worked the other 
direction looking for a field mark, which it would never find either.  There 
was a two card program you could put in front of  your card deck that would 
zero memory then load your program, but since the model 1 did addition by table 
lookup in locations 100-199, if there was any chance that table was bad, it 
would not work.  I think other "catch fire" instruction variants would continue 
forever.

2. remember that record mark? if you ever executed an instruction with a record 
mark in the address, you got a MAR check red light, a hard reset was required 
to escape.  probably if in the op code also.  And some hard stop for any 
invalid op code, but these may have been in the category below.

3. there were other errors, but you could press start to continue and there was 
a toggle switch to ignore at least some of them, like a parity error in memory.

4. I seem to recall being told "don't do this, it can break the hardware", but 
don't remember any details, and not an instant thing, it would be like the "B 
*" loop, causing issues if left running a long time.

The IBM 1401 had a similar architecture (but with 7 useable bits per address vs 
5 for the 1620, and was also memory to memory, so probably had instructions 
that would run forever.  No typewriter available on the 1401 AFAIK, so my 
example would not have been a routine action..


--Carey