Multiplan for the VT180

[Paul Anderson]

While looking for some other docs, I found a few new copies of Multiplan
for the VT180, NOS. White folder, 2 books, sealed floppy.

If you have any questions or interest, please contact me off list. Easy to
mail from zip 61853.

Paul

Re: Reproduction micros

[Peter Corlett]

On Mon, Jul 25, 2016 at 01:46:43PM -0700, Guy Sotomayor Jr wrote:
>> On Jul 25, 2016, at 1:34 PM, Sean Conner  wrote:
>> It was thus said that the Great Peter Corlett once stated:
>>> Unsurprisingly, the x86 ISA is brain-damaged here, in that some
>>> instructions (e.g. inc") only affect some bits in EFLAGS, which causes a
>>> partial register stall. The recommended "fix" is to avoid such
>>> instructions.

>>  I'm not following this.  On the x86, the INC instruction modifies the
>> following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
>> a partial register stall, therefore, I need to use ADD.  Let me check ...
>> hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
>> avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
>> addition routine ... 
>>  -spc (Or am I missing something?)

Yes, in that I was taking a potshot at x86's expense, and skipped the technical
details because contemporary x86 architecture is seriously off-topic. But since
I've now been asked...

> No Peter is wrong. All of the modern x86 (at least the Intel CPUs) are OOO
> machines with large register files (192 comes to mind) that do register
> renaming to map the register(s) used by a particular instruction back into an
> “architectural” register (no copy is actually done). The flags register is
> also part of the register re-naming. The only stalls occur when one
> instruction needs the results from an instruction that hasn’t committed it’s
> results yet (ie the instruction is still in “flight”).

It is the *partial* update that's key. If you do an INC and then read EFLAGS or
execute an instruction such as JBE that needs C and some other flag(s), the
information has to be derived from *two* renamed registers. This typically
involves an extra micro-op in the instruction stream to do this fixup, although
the details will obviously vary by CPU model.

But I'm only repeating this information from the experts, so if you still think
I'm wrong, read their reference material:

http://www.agner.org/optimize/microarchitecture.pdf is Agner Fog's optimisation
guide with more detail that mere mortals really need. Page 154 covers this for
the latest Skylake CPUs and uses INC in its example.

http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html
is Intel's own optimisation guide. Section 3.5.2.6 discusses partial flag
register stalls, although it doesn't specifically mention INC.

This stuff is way more complex than any normal person can keep in their head.
It's possible to learn all the edge cases and avoid the performance hit in
hand-written assembly, but it's a lot easier to just give it to the compiler to
puzzle out. That's its job.

Can we now go back to talking about interesting CPUs? :)

Re: Reproduction micros

[Guy Sotomayor Jr]

> On Jul 25, 2016, at 1:34 PM, Sean Conner  wrote:
> 
> It was thus said that the Great Peter Corlett once stated:
>> 
>> Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
>> (e.g. inc") only affect some bits in EFLAGS, which causes a partial register
>> stall. The recommended "fix" is to avoid such instructions.
> 
>  I'm not following this.  On the x86, the INC instruction modifies the
> following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
> a partial register stall, therefore, I need to use ADD.  Let me check ...
> hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
> avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
> addition routine ... 
> 
>  -spc (Or am I missing something?)

No Peter is wrong.  All of the modern x86 (at least the Intel CPUs) are OOO
machines with large register files (192 comes to mind) that do register renaming
to map the register(s) used by a particular instruction back into an 
“architectural”
register (no copy is actually done).  The flags register is also part of the 
register 
re-naming.  The only stalls occur when one instruction needs the results from an
instruction that hasn’t committed it’s results yet (ie the instruction is still 
in “flight”).

TTFN - Guy

Re: Reproduction micros

[Sean Conner]

It was thus said that the Great Peter Corlett once stated:
> 
> Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
> (e.g. inc") only affect some bits in EFLAGS, which causes a partial register
> stall. The recommended "fix" is to avoid such instructions.

  I'm not following this.  On the x86, the INC instruction modifies the
following flags: O, S, Z, A and P.  So okay, I need to avoid INC to prevent
a partial register stall, therefore, I need to use ADD.  Let me check ...
hmm ... ADD modifies the following: O, S, Z, A, P and C.  So now I need to
avoid ADD as well?  I suppose I could use LEA but then there goes my bignum
addition routine ... 

  -spc (Or am I missing something?)

Re: APL-100

[Diane Bruce]

On Mon, Jul 25, 2016 at 10:24:50AM -0600, Norman Jaffe wrote:
> Hi: 
> 

As a local to Ottawa this piqued my curiosity.

I found this
http://www.americanradiohistory.com/Archive-Electronics-Today/70s/Electronics-Today-1979-11.pdf


Video Terminal 
The Cybernex APL -100 terminal fea-
tures true overstrikes using a highly 
legible 9x13 dot character cell and 
a 1920 character 80 by 24 display with
selectable 48 line, 32 character split 
screen mode which scrolls all 48 lines 
from bottom right to top left. 
Standard features of the APL -100 in 
both ASCII and APL modes include
read and write cursor address, four 
direction cursor control, page printand 
printer port on/off control.
The list price of the APL -100 
is $1795.00 Canadian, FOB Ottawa, 
Ontario, Canada, (no taxes included), 
with delivery beginning in September, 
1979. 
For full information on the APL -100 
terminal or the 6 standard models of 
video terminals, contact Bruce Doug- 
las, V.P. Marketing, 2183 Dunwin Drive, 
Mississauga, Ontario, Canada, phone 
(416) 828-2810 or Wayne Reid in 
Ottawa, at (613) 741-1540. 

The University of Ottawa was big into APL\360 at one time. I remember
the old golf ball terminals they used. Carleton U eventually got
the golf ball terminals and APL terminals on their Xerox system.
The 'golf ball' (2741 terminal) were still being used despite the
glass TTYs being available at Carleton since no tty at that time had
the APL character set. This APL-100 would have been useful to both
Carleton and Ottawa U if they were still using APL when it came out ;)
but I never one of these in use.

The 741 exchange strikes me as being from Eastview (at the time) nowadays
known as Vanier I wonder where this guy was. Probably Montreal road.
(Just east of Wellington here in Ottawa)

- Diane
-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db

Re: APL-100

[Norman Jaffe]

Hi Lee: 

I am aware of the CHM files and I have a number of APL documents that might not 
be in the archive - I'll check sometime this week. 
- Original Message -

From: "Lee Courtney"  
To: "General Discussion: On-Topic Posts" , 
tur...@shaw.ca 
Sent: Monday, July 25, 2016 8:12:41 AM 
Subject: Re: APL-100 


Hi Norman, 


I don;t have any specific information on this terminal, but wanted to make sure 
you are aware of the APL archive hosted at the Computer History Museum - 
http://www.softwarepreservation.org/projects/apl/ 


If you run across any APL material not already in the archive please pass along 
a copy and I'd love to add it. 


Thanks! 


Lee Courtney 


On Mon, Jul 25, 2016 at 6:07 AM, Norman Jaffe < tur...@shaw.ca > wrote: 


Hi: 

I just recently acquired a Cybernex APL-100 APL/ASCII terminal; it appears to 
be complete, but the only documentation that I have for it is a sales brochure. 
Is there anyone familiar with this? It was manufactured in Ottawa, Ontario 
(Canada) in the late '70s - any technical information would be appreciated. 






-- 


Lee Courtney 
+1-650-704-3934 cell 

Re: APL-100

[Norman Jaffe]

Hi: 

I found a picture at 
http://omolini.steptail.com/mirror/www.classiccmp.org/dunfield/tty/index.htm 
that looks just like the terminal that I received. 
- Original Message -

From: "Mike Stein"  
To: "General Discussion: On-Topic Posts"  
Sent: Monday, July 25, 2016 9:10:08 AM 
Subject: Re: APL-100 

Is there a picture of this terminal available anywhere? 

TIA, m 

- Original Message - 
From: "Norman Jaffe"  
To: "General Discussion: On-Topic Posts"  
Sent: Monday, July 25, 2016 9:07 AM 
Subject: APL-100 


> Hi: 
> 
> I just recently acquired a Cybernex APL-100 APL/ASCII terminal; it appears to 
> be complete, but the only documentation that I have for it is a sales 
> brochure. 
> Is there anyone familiar with this? It was manufactured in Ottawa, Ontario 
> (Canada) in the late '70s - any technical information would be appreciated. 

Re: APL-100

[Mike Stein]

Is there a picture of this terminal available anywhere?

TIA, m

- Original Message - 
From: "Norman Jaffe" 
To: "General Discussion: On-Topic Posts" 
Sent: Monday, July 25, 2016 9:07 AM
Subject: APL-100


> Hi: 
> 
> I just recently acquired a Cybernex APL-100 APL/ASCII terminal; it appears to 
> be complete, but the only documentation that I have for it is a sales 
> brochure. 
> Is there anyone familiar with this? It was manufactured in Ottawa, Ontario 
> (Canada) in the late '70s - any technical information would be appreciated.

Re: APL-100

[Lee Courtney]

Hi Norman,

I don;t have any specific information on this terminal, but wanted to make
sure you are aware of the APL archive hosted at the Computer History Museum
- http://www.softwarepreservation.org/projects/apl/

If you run across any APL material not already in the archive please pass
along a copy and I'd love to add it.

Thanks!

Lee Courtney

On Mon, Jul 25, 2016 at 6:07 AM, Norman Jaffe  wrote:

> Hi:
>
> I just recently acquired a Cybernex APL-100 APL/ASCII terminal; it appears
> to be complete, but the only documentation that I have for it is a sales
> brochure.
> Is there anyone familiar with this? It was manufactured in Ottawa, Ontario
> (Canada) in the late '70s - any technical information would be appreciated.
>



-- 
Lee Courtney
+1-650-704-3934 cell

APL-100

[Norman Jaffe]

Hi: 

I just recently acquired a Cybernex APL-100 APL/ASCII terminal; it appears to 
be complete, but the only documentation that I have for it is a sales brochure. 
Is there anyone familiar with this? It was manufactured in Ottawa, Ontario 
(Canada) in the late '70s - any technical information would be appreciated. 

ExpandaCore 18 core memory

[Göran Axelsson]

Hi again...

My recent adventures with the StorageTek tape unit is on hold since I 
got a whole new computer to play with... (and because the disk on my 
linux with SCSI card had gone bad). A NORD-1 by Norsk Data AS (or Norsk 
Dataelektronikk AS as the company was called in those days). It is a 
computer built from TTL chips, a whopping 2250 of them. I seems to be in 
great shape and I even have drawings of the most of the CPU.


More about it here : http://www.ndwiki.org/wiki/NORD-1_Serial_47 ... 
with pictures. :-)


The NORD-1 was designed in 1967, the first one was sold in 1969 and 
somewhere between 60 and 120 were produced until it was succeeded by the 
NORD-10. A few NORD-1 ended up in Cern.


The power supplies all was within 0,05V from nominal, not bad for a 44 
year old computer. And except from a few broken switches, a shorted 
capacitor (mechanical damage) and a few missing cards it is in "running 
condition". Well, liberally used definition, it sort of runs. I can set 
the address register and inspect the different registers. When put in 
continuous mode the program counter runs through and loops the memory.


My guess so far is that there is a problem with reading and writing to 
the memory. The problem is that I have no documentation over the memory 
module except a drawing of the circuitry used to access it. ND bought 
several different models of core memory for it's early computers and 
just adapted the interface.


So once again I turn to the cctech for help, does anybody have 
instructions about ExpandaCore 18 from by Cambridge Memories INC, 
Newton, Massachusetts (also known as CMI but probably not the CMI on 
bitsavers).
So far the only thing I've found was a newsflash in a computer magazine 
about a sale of memories to another computer maker.


My plan is to have this machine up and running within a year, in time 
for the 50 year anniversary of ND founding. :-)


... and this is a long shot, if anyone has a copy of ND-NEWS (ND-NYTT in 
Norwegian) I would like to have a scan of it. There might be an article 
in it about delivering this machine to the school that I got it from.


Thanks in advance, Göran

Re: GE Canada are hiring... A PDP-11 programmer

[Adrian Stoness]

As far as I know they might still be

On Jul 25, 2016 8:35 AM, "Liam Proven"  wrote:

> On 25 July 2016 at 02:26, Ali  wrote:
> > Huh? That post is over three years old. Am I missing something?
> >
> >
>
>
> Aargh! Sorry. Perils of posting at 2AM after beer. Apologies.
>
> --
> Liam Proven • Profile: http://lproven.livejournal.com/profile
> Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
> MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
> Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)
>

Re: Reproduction micros

[Paul Koning]

> On Jul 25, 2016, at 12:19 PM, Chuck Guzis  wrote:
> 
> On 07/25/2016 02:31 AM, Peter Corlett wrote:
> 
>> Eliminating condition codes just moves the complexity from the ALU to
>> the branch logic (which now needs its own mini-ALU for comparisons),
>> and there's not much in it either way. Where it *does* win is that
>> the useful instructions are all single-output and so one can use the
>> noddy code generators found in undergraduate-level compiler
>> construction textbooks such as the Dragon Book.
> 
> Sorry, I'm not following this bit.  I am speaking about a three-address
> ISA here, BTW.
> 
> Simply adding a flag to each register reflecting its zero/nonzero
> content should do the job.  The high-order (sign) bit is the only other
> bit necessary.  Branch instructions need only inquire if either, neither
> or both flags are set.
> 
> I suppose that one could also have several flags registers, being set
> selectively as dictated by a field in the instruction.

The point is that instructions that set condition codes have two outputs: their 
output register, and the condition code register.

That creates both software and hardware complexity.  Software complexity in the 
compiler, which has to track the assignments to both these outputs and do 
instruction rearranging accordingly.  Hardware complexity, because the 
instruction issue logic has to issue the instructions for the correct outcome 
in both these outputs.

paul

Re: Reproduction micros

[Chuck Guzis]

On 07/25/2016 02:31 AM, Peter Corlett wrote:

> Eliminating condition codes just moves the complexity from the ALU to
> the branch logic (which now needs its own mini-ALU for comparisons),
> and there's not much in it either way. Where it *does* win is that
> the useful instructions are all single-output and so one can use the
> noddy code generators found in undergraduate-level compiler
> construction textbooks such as the Dragon Book.

Sorry, I'm not following this bit.  I am speaking about a three-address
ISA here, BTW.

Simply adding a flag to each register reflecting its zero/nonzero
content should do the job.  The high-order (sign) bit is the only other
bit necessary.  Branch instructions need only inquire if either, neither
or both flags are set.

I suppose that one could also have several flags registers, being set
selectively as dictated by a field in the instruction.

--Chuck

Re: GE Canada are hiring... A PDP-11 programmer

[Liam Proven]

On 25 July 2016 at 02:26, Ali  wrote:
> Huh? That post is over three years old. Am I missing something?
>
>


Aargh! Sorry. Perils of posting at 2AM after beer. Apologies.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lpro...@hotmail.com • Skype/AIM/Yahoo/LinkedIn: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: Reproduction micros

[Peter Corlett]

On Mon, Jul 25, 2016 at 05:54:51AM -0600, ben wrote:
[...]
> The other factor is that the 3 big computers at the time IBM 360/370's PDP 10
> and PDP 11 where machines when the Dragon Book came out thus you favored
> register style code generators. Later you got the Pascal style one pass
> generators that is still with us.

Those backend designs are completely obsolete now. Modern machines have more
grunt, so can use more complex algorithms to eke out more performance.

> After that the Intel hardware mess, and the growth of (to me useless
> languages like C++ or JAVA) or features like OBJECTS has made every thing so
> complex, that only few people can even understand just what a compiler is
> doing.

A C++ object is a C struct, and a C++ method is a C function that has an
invisible first parameter that is a pointer to the object. The generated
machine code is bitwise identical. Dynamic dispatch muddies the water a bit,
and is equivalent to (but not usually implemented as) a function pointer in the
struct. This is not exactly rocket science.

There are more features in C++, and they tend to get overused by newcomers who
are blinded by the shinies, but it is possible to exercise good judgement to
make it *easier* to read than the equivalent C program by tucking all the
boilerplate out of the way.

> PS: Has computer science really advanced since the late 1970's? What about
> hardware?

Is that a rhetorical question? I'm going to answer it anyway :)

One of my favourite bits of CS is Andrew Tridgell's PhD thesis, from 1999. The
advancement to human knowledge was his algorithm to very efficiently run a
sliding window across data using rolling checksums and compute deltas in a
network-efficient manner. This is the business end of rsync(1), and it can also
be used for data compression.

On compilation itself, there are a few interesting advances. Single Static
Assignment form was invented by IBM in the 1980s; ISTR it's covered in my 1986
edition of the Dragon Book. The essence of the idea is that variables can only
be assigned once, and since they are immutable values, it enables many very
worthwhile optimisations that wouldn't be as simple were the values liable to
change.

Functional programming is finally mainstream. Yes, Lisp has been around since
the 1950s, but it's been refined somewhat over the 2000s. It's used for
immutability (which Lisp didn't really have) and so is easier to reason about
on multi-threaded and multi-processor machines because one now doesn't need to
worry about shared mutable state.

There are *loads* of novel algorithms and techniques out there, but it seems to
take decades for them to appear in algorithm textbooks.

Re: Reproduction micros

[ben]

On 7/25/2016 3:31 AM, Peter Corlett wrote:

On Fri, Jul 22, 2016 at 11:59:59AM -0700, Chuck Guzis wrote:
[..]

Something that's always bothered me about three-address architectures like
ARM is why there is the insistence on that scheduling bottleneck, the
condition code register? You can see how two-address architectures like the
x80 and x86 try to get around the problem by having certain instructions not
modify certain condition code bits and even have specialized instructions,
such as JCXZ, that don't reply on a specific condition code.



Anyone have a clue?


The condition code register can be treated as a regular register that partakes
in register renaming. Effectively, you have *many* CCRs in flight, so only
*reads* of the register may cause stalls. These reads are usually branches, so
there's branch prediction caches to try and deal with those stalls.

Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
(e.g. inc") only affect some bits in EFLAGS, which causes a partial register
stall. The recommended "fix" is to avoid such instructions.

Eliminating condition codes just moves the complexity from the ALU to the
branch logic (which now needs its own mini-ALU for comparisons), and there's
not much in it either way. Where it *does* win is that the useful instructions
are all single-output and so one can use the noddy code generators found in
undergraduate-level compiler construction textbooks such as the Dragon Book.

I favor testing a register rather than using  flags.(I also like 9 bit 
bytes too).

The other factor is that
the 3 big computers at the time IBM 360/370's PDP 10 and PDP 11 where 
machines when the Dragon Book came out thus you favored register style 
code generators. Later you got the Pascal style one pass generators that 
is still with us. After that the Intel hardware mess, and the growth of 
(to me useless languages like C++ or JAVA) or features like OBJECTS has 
made every thing so complex, that only few people can even

understand just what a compiler is doing.

Ben.
PS: Has computer science really advanced since the late 1970's?
What about hardware?

Re: seeking DEC VAXmate software

[Nigel Williams]

On Sun, Jul 24, 2016 at 11:30 PM, Camiel Vanderhoeven
 wrote:
> Yes, it's an optional expansion box. The idea behind the vaxmate was that
> instead of from a hard disk, it could run from a disk image on a VAX, so a
> local hard disk was optional.

ComputerWorld once wrote:

"... In the confusion of DEC's Micro Channel feelers (see page 1), DEC
officials said their own
Vaxmate is not a PC; it's a networking product. But on Friday, a DEC spokesman
included the system in a list of DEC's past PC offerings; this reminded us
that DEC President Ken Olsen called the Vaxmate a corporate PC when it was
introduced in 1986. Following the Tandy deal, cynics quickly noted, the Vaxmate
may soon not be a product at all. If you have the line on DEC's PC strategy
of the month, call the hot line at..."

Re: Reproduction micros

[Peter Corlett]

On Fri, Jul 22, 2016 at 11:59:59AM -0700, Chuck Guzis wrote:
[..]
> Something that's always bothered me about three-address architectures like
> ARM is why there is the insistence on that scheduling bottleneck, the
> condition code register? You can see how two-address architectures like the
> x80 and x86 try to get around the problem by having certain instructions not
> modify certain condition code bits and even have specialized instructions,
> such as JCXZ, that don't reply on a specific condition code.

> Anyone have a clue?

The condition code register can be treated as a regular register that partakes
in register renaming. Effectively, you have *many* CCRs in flight, so only
*reads* of the register may cause stalls. These reads are usually branches, so
there's branch prediction caches to try and deal with those stalls.

Unsurprisingly, the x86 ISA is brain-damaged here, in that some instructions
(e.g. inc") only affect some bits in EFLAGS, which causes a partial register
stall. The recommended "fix" is to avoid such instructions.

Eliminating condition codes just moves the complexity from the ALU to the
branch logic (which now needs its own mini-ALU for comparisons), and there's
not much in it either way. Where it *does* win is that the useful instructions
are all single-output and so one can use the noddy code generators found in
undergraduate-level compiler construction textbooks such as the Dragon Book.