Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Phil Budne]

Bob Eager wrote:
> How many people have read this book? (I have it)
I own it, but have never studied it.

> It's about the design of an early BLISS compiler.
BLISS-11

>  http://amzn.eu/irCsXhi 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Bob Eager]

On Fri, 26 Jan 2018 22:55:48 +0100
Johnny Billquist  wrote:

> Heh. I've had similar experiences with BLISS-16. I've learned a trick
> or two looking at the code generated, and it can do some rather neat 
> tricks. Definitely impressive code generated. Not seen that level
> from any other PDP-11 compiler.

How many people have read this book? (I have it)

It's about the design of an early BLISS compiler.

 http://amzn.eu/irCsXhi 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Paul Koning]

> On Jan 26, 2018, at 4:59 PM, Johnny Billquist  wrote:
> 
> On 2018-01-26 22:49, Timothe Litt wrote:
>> ...
>> There also was the argument that you really couldn't (well, shouldn't) write 
>> pure assembler for Alpha because the best scheduling depends on the 
>> implementation (how many execution units, of what sorts & latencies; 
>> predictions, speculations, prefetch; etc.)
>> PALcode has some unique constraints that do require manual scheduling, as do 
>> some diagnostics.  But it does turn out to be true that Alpha assembler is 
>> best understood (and used) as a low-level compiled language, not an 
>> assembler.
> 
> Are we talking about MACRO-32 or Alpha assembler now? They are two different 
> things. PALcode, I would assume, you actually wanted an Alpha assembler for. 
> Porting lots of VMS stuff needed the MACRO-32 compiler. Exactly what Paul was 
> doing, and in which language, was a bit unclear to me. I was assuming he was 
> talking about Alpha assembler, and not MACRO-32, but I could be wrong.

Yes, native Alpha assembler.  Obviously that is machine dependent if you're 
optimizing very seriously.  The purpose of the exercise was to see if you could 
do TCP checksum in software while moving network data between the Ethernet NIC 
buffers and other places, at the same speed as a simple memcpy.  The answer is 
yes: if you're at all careful, you can do the necessary arithmetic at times 
when the CPU would otherwise have been waiting for memory accesses.  The same 
tends to be true for simple data processing actions on buffers in many other 
machines, for that matter.  Many years later I did RAID-5 and RAID-6 (XOR 
based) in software in a similar way, the cost was simply that of passing over 
the memory buffers and the arithmetic involved had an effective cost of zero.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Johnny Billquist]

On 2018-01-26 22:49, Timothe Litt wrote:


On 26-Jan-18 14:45, Paul Koning wrote:

ent.​  I also do not know what they are doing with the front-ends.
One of the more curious front ends of GEM is the Alpha assembler.  I found out about that 
when doing some Alpha hand-optimizing early on (a handcoded "memcpy with TCP 
checksum calculation while doing it" if I remember right).  It turned out I could 
write drafts of that code and give it to the assembler with a /OPTIMIZE switch to let the 
back end take what I wrote and do stuff to it.  It wasn't always right, but it was a neat 
source of ideas.
Well, not exactly an optimizing assembler.  It sort of looks like one.  
But the real story is that the Alpha port needed to deal with the large 
amount of MACRO-32 in VMS.  The solution was to treat MACRO-32 as a 
compiled language, and generate a GEM front end for it.  There was a lot 
of optimization that was absolutely required if you wanted tolerable 
code - e.g. most VAX instructions set condition codes, but they are 
rarely tested - and when tested, usually only a subset of those set are 
involved in the test.  So tracking condition code generation and 
consumption is a big win.  And when you look at address generation, 
there's a lot of opportunity for CSE elimination, and other 
optimizations.  Then you wanted to schedule the generated code for Alpha 
- which is a lot of re-ordering, packing & the like.


Then it was extended for the Alpha instruction set (psect attributes, 
instructions, etc).


At this point, you have a compiler for low level language, that happens 
to look like assembler.  Externally, perhaps a distinction without a 
difference; internally, quite different.  And if you're unlucky enough 
to have to do instruction level debug, very different from traditional 
assembler.


There also was the argument that you really couldn't (well, shouldn't) 
write pure assembler for Alpha because the best scheduling depends on 
the implementation (how many execution units, of what sorts & latencies; 
predictions, speculations, prefetch; etc.)


PALcode has some unique constraints that do require manual scheduling, 
as do some diagnostics.  But it does turn out to be true that Alpha 
assembler is best understood (and used) as a low-level compiled 
language, not an assembler.


Are we talking about MACRO-32 or Alpha assembler now? They are two 
different things. PALcode, I would assume, you actually wanted an Alpha 
assembler for. Porting lots of VMS stuff needed the MACRO-32 compiler. 
Exactly what Paul was doing, and in which language, was a bit unclear to 
me. I was assuming he was talking about Alpha assembler, and not 
MACRO-32, but I could be wrong.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Johnny Billquist]

On 2018-01-26 22:49, Hunter Goatley wrote:

On 1/26/2018 3:28 PM, Timothe Litt wrote:

Sounds right.  The -16 and -36 versions stayed with the native backend 
and didn't get much attention once GEM took off.  At least, I don't 
recall GEM support for them.


I believe that's correct.


So, no GEM for BLISS-16, and most likely no chance of it being ported to 
Alpha then. Thanks for confirming that.


All three (CMU ,BLISS, GEM) back ends used considerable creativity in 
interpreting the instruction sets, and as time went on gave hand-coded 
assembler a run for its money.  They especially liked to do 
computations with bizarre-looking address calculations.  (Not all of 
which ran fast on all processors.) In one case, a particularly 
"clever" encoding of a test on a link-time constant broke RMS on an 
unreleased VAX CPU. Interestingly, this one instruction was the ONLY 
time this construct was encountered in all of VMS (including the top 
dozen layered products), so waiting for the hardware spin wasn't as 
bad as it might have been.


I vaguely remember hearing about that.

BLISS-32 on VAX generated some amazing optimizations. Before I got into 
BLISS, I programmed almost exclusively in MACRO-32, and it was fun to 
compare code I wrote to the assembly code generated by the BLISS 
compiler. Several times, I encountered generated code that was a lot 
more efficient than the code I wrote, which I thought was very 
efficient. I learned a few MACRO tricks looking at the code generated. 
It was less fun trying to understand the GEM output for Alpha. ;-)


Heh. I've had similar experiences with BLISS-16. I've learned a trick or 
two looking at the code generated, and it can do some rather neat 
tricks. Definitely impressive code generated. Not seen that level from 
any other PDP-11 compiler.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS

[Howard Bussey]

SOAP was the assembler for the IBM 650.

—Howard

Sent from my iPhone

> On Jan 26, 2018, at 16:25, Larry Baker  wrote:
> 
> Was SOAP Knuth's assembler that optimized placement of the machine code on 
> the drum memory to minimize access latency for the next instruction?
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
>> On 26 Jan 2018, at 12:35:20 PM, simh-requ...@trailing-edge.com wrote:
>> 
>> The only other optimizing assembler I can think of is SOAP, way back in the 
>> 1950s.
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Timothe Litt]

On 26-Jan-18 14:45, Paul Koning wrote:
> ent.​  I also do not know what they are doing with the front-ends.  
> One of the more curious front ends of GEM is the Alpha assembler.  I found 
> out about that when doing some Alpha hand-optimizing early on (a handcoded 
> "memcpy with TCP checksum calculation while doing it" if I remember right).  
> It turned out I could write drafts of that code and give it to the assembler 
> with a /OPTIMIZE switch to let the back end take what I wrote and do stuff to 
> it.  It wasn't always right, but it was a neat source of ideas.
Well, not exactly an optimizing assembler.  It sort of looks like one. 
But the real story is that the Alpha port needed to deal with the large
amount of MACRO-32 in VMS.  The solution was to treat MACRO-32 as a
compiled language, and generate a GEM front end for it.  There was a lot
of optimization that was absolutely required if you wanted tolerable
code - e.g. most VAX instructions set condition codes, but they are
rarely tested - and when tested, usually only a subset of those set are
involved in the test.  So tracking condition code generation and
consumption is a big win.  And when you look at address generation,
there's a lot of opportunity for CSE elimination, and other
optimizations.  Then you wanted to schedule the generated code for Alpha
- which is a lot of re-ordering, packing & the like.

Then it was extended for the Alpha instruction set (psect attributes,
instructions, etc).

At this point, you have a compiler for low level language, that happens
to look like assembler.  Externally, perhaps a distinction without a
difference; internally, quite different.  And if you're unlucky enough
to have to do instruction level debug, very different from traditional
assembler.

There also was the argument that you really couldn't (well, shouldn't)
write pure assembler for Alpha because the best scheduling depends on
the implementation (how many execution units, of what sorts & latencies;
predictions, speculations, prefetch; etc.)

PALcode has some unique constraints that do require manual scheduling,
as do some diagnostics.  But it does turn out to be true that Alpha
assembler is best understood (and used) as a low-level compiled
language, not an assembler.

> The only other optimizing assembler I can think of is SOAP, way back in the 
> 1950s.
>
>   paul
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Hunter Goatley]

On 1/26/2018 3:28 PM, Timothe Litt wrote:

Sounds right.  The -16 and -36 versions stayed with the native backend 
and didn't get much attention once GEM took off.  At least, I don't 
recall GEM support for them.


I believe that's correct.

Alpha pretty much repeated the VAX route (plus the stupid mistake of 
splitting the VMS sources).  It cross-compiled from VAX to simulation,


I was porting a lot of freeware from VAX to Alpha when all that was 
available were the cross-compilers. The BLISS cross-compiler was great, 
but the early C cross-compilers were more problematic.


All three (CMU ,BLISS, GEM) back ends used considerable creativity in 
interpreting the instruction sets, and as time went on gave hand-coded 
assembler a run for its money.  They especially liked to do 
computations with bizarre-looking address calculations.  (Not all of 
which ran fast on all processors.) In one case, a particularly 
"clever" encoding of a test on a link-time constant broke RMS on an 
unreleased VAX CPU. Interestingly, this one instruction was the ONLY 
time this construct was encountered in all of VMS (including the top 
dozen layered products), so waiting for the hardware spin wasn't as 
bad as it might have been.


I vaguely remember hearing about that.

BLISS-32 on VAX generated some amazing optimizations. Before I got into 
BLISS, I programmed almost exclusively in MACRO-32, and it was fun to 
compare code I wrote to the assembly code generated by the BLISS 
compiler. Several times, I encountered generated code that was a lot 
more efficient than the code I wrote, which I thought was very 
efficient. I learned a few MACRO tricks looking at the code generated. 
It was less fun trying to understand the GEM output for Alpha. ;-)


Every time I do handstands with C #if/#define I still wish for BLISS 
%if and %macro.  (I once had to port a few 100K lines of my BLISS code 
to C on a 68000, and even with automation, converting macros and 
keyword initialized data structures to C was a painful exercise in 
devolution by obfuscation...)


Yes, the BLISS macros and lexicals are awesome, and it also kills me 
that C never had them.


Hunter

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

below.. at bit off topic from simulators  sorry

On Fri, Jan 26, 2018 at 3:35 PM, Hunter Goatley 
wrote:

> On 1/26/2018 2:22 PM, Timothe Litt wrote:
>
>>
>> BLISS would have done better in the outside world, except for the
>> DECision to price it higher than the market would bear.
>>
>
> Indeed! I was fortunate to get access to BLISS in college thanks to DEC's
> CSLG program, but it was their second-most expensive compiler license
> (after Ada), so virtually no one outside of DEC used it. When they
> originally released Alpha, they weren't planning to make the BLISS compiler
> available, but I and others worked to try to get DEC to change that. As I'm
> sure you know, in the end, they released it with a free license for both
> VAX and Alpha (and Itanium), but it was far too late for most people to
> have any interest in adopting it. I still do some BLISS coding, but I'm one
> of the few that I know of still doing it.


​Yup it was hard to for $5K / cpu to compete with $100 plus you got the
sources and could run it on any system - - certainly for any university.
And what DEC failed to understand was both the power of the new
microprocessors and that university hacker types would want to mess with
the compiler itself.

Tim - while I agree BLISS at the time was a more complete/better language
--- the difference in the quality of the code that they generated was night
and day - assuming you have made it self hosting etc... but . I have
also wondered if "free" would have been good enough though.   Access to the
sources so you could retarget it was a huge thing that helped C spread.  In
my own case, in the summer of 1979 when we go the experimental parts at
Tektronix that would later become the 68000, I wanted/needed an HLL to mess
with it.   What did I do? I hacked on the Ritchie C compiler and made a
crude backend -- good enough for an OS guy to do his work.

A year or so after that, when we did the TCP implementation, we needed a
HLL for our Vax (running VMS).  I did manage to get Tek to buy a BLISS
license for it.   But I remember all of us be amazed that DEC was trying to
charge so much for it.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Timothe Litt]

On 26-Jan-18 14:09, Clem Cole wrote:
>
>
> The other thing to add is there were at least two generations of the
> compilers within DEC that I knew about. 
Yes. 
> Tim you may have know of a third when I was off doing other things.  
> The last (current) is the 'Gem' compilers which was a rewrite to allow
> N font-ends, with Y back-ends.   I thought 'Compatible BLISS' was done
> to create BLISS-36/16/32 (PDP-10, 11, Vax) from the original CMU base;
> but was only targeting BLISS. 
Yes - "Common BLISS", not "compatible".  But Common BLISS also included
a lot of language changes.

> AFAIK, the original Compatible BLISS compiler was developed on the
> PDP-10 and eventually replaced the CMU code. 
Yes - VMS was initially developed under TOPS-20 with the cross tools. 
The developers were happy when it became self-hosted on the VAX, though
they lost a lot in moving from a mature environment.  But pride of self
covers a lot of pain.

The LCG products moved to Common BLISS - FORTRAN, RMS, APL perhaps the
most notable.  One or two might have been left behind because they were
so stable.  But none come immediately to mind.

> Prism forced the rewrite of the back-ends and with it the later
> generation and TLG wanted to clean up its act with a single
> back-end/optimizer that was common for all the languages [hence the
> Gem project - I'd have to ask Rich Grove for the details].  IIRC, Vax
> was used as the base for that system, although it moved to Alpha by
> the mid/late 1990s.
>
Sounds right.  The -16 and -36 versions stayed with the native backend
and didn't get much attention once GEM took off.  At least, I don't
recall GEM support for them.  However, there was minimal change to the
language, so Common BLISS remained common.  (I think the changes were
stuff like architecture-specific PSECT attributes, alignments &
builtins.)  GEM was very successful in consolidating optimization
efforts across all the languages.  It also made it feasible to add
object code generation for various runtime environments for multiple
languages.  Turned an n * m problem into essentially n + m.

Alpha pretty much repeated the VAX route (plus the stupid mistake of
splitting the VMS sources).  It cross-compiled from VAX to simulation,
then the internal early development alpha subset hardware, then alpha. 
But it was a lot easier, since we had real networks and
cross-architecture clusters; you could compile on a VAX, dismount the
disk, and boot on an Alpha ADU in about 30 seconds; later, compile on a
VAX and run user mode on Alpha without dismounting.  OSF/1 was another
story; I wasn't involved in that.

Because of GEM, compiler "generation" gets a bit fuzzy - updates give
BLISS new optimizations and targets (some radically different), but
(almost) all the work is in GEM, not the front end.  But GEM would race
along for a while, but not be incorporated into the released languages
until there was some forcing function.  That could be a long time for
BLISS, but not so long for FORTRAN and C.  So it depends on where you
draw the line - is GEM part of the compiler, or not?  No doubt the
compiler guys can point to examples where GEM changes affected the
language front ends, but from afar it seemed a pretty stable interface. 
I don't think there was any technical reason that the front end, IL
optimizer, code generators and object generators couldn't have been
separate sharable libraries - and separately patchable/upgradable.  But
I suspect there was marketing (and qualification) pull toward hiding the
boundaries when packaging.  After all, some 3rd party might have written
a backend for a non-DEC architecture.

All three (CMU ,BLISS, GEM) back ends used considerable creativity in
interpreting the instruction sets, and as time went on gave hand-coded
assembler a run for its money.  They especially liked to do computations
with bizarre-looking address calculations.  (Not all of which ran fast
on all processors.)  In one case, a particularly "clever" encoding of a
test on a link-time constant broke RMS on an unreleased VAX CPU. 
Interestingly, this one instruction was the ONLY time this construct was
encountered in all of VMS (including the top dozen layered products), so
waiting for the hardware spin wasn't as bad as it might have been.

Every time I do handstands with C #if/#define I still wish for BLISS %if
and %macro.  (I once had to port a few 100K lines of my BLISS code to C
on a 68000, and even with automation, converting macros and keyword
initialized data structures to C was a painful exercise in devolution by
obfuscation...)


> Clem
>
> ᐧ



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS

[Larry Baker]

Was SOAP Knuth's assembler that optimized placement of the machine code on the 
drum memory to minimize access latency for the next instruction?

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



> On 26 Jan 2018, at 12:35:20 PM, simh-requ...@trailing-edge.com wrote:
> 
> The only other optimizing assembler I can think of is SOAP, way back in the 
> 1950s.



smime.p7s
Description: S/MIME cryptographic signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Timothe Litt]

On 26-Jan-18 15:54, Rich Alderson wrote:
>> Date: Fri, 26 Jan 2018 14:35:18 -0600
>> From: Hunter Goatley 
>> On 1/26/2018 2:22 PM, Timothe Litt wrote:
>>> BLISS would have done better in the outside world, except for the 
>>> DECision to price it higher than the market would bear.
>> Indeed! I was fortunate to get access to BLISS in college thanks to 
>> DEC's CSLG program, but it was their second-most expensive compiler 
>> license (after Ada), so virtually no one outside of DEC used it. When 
>> they originally released Alpha, they weren't planning to make the BLISS 
>> compiler available, but I and others worked to try to get DEC to change 
>> that. As I'm sure you know, in the end, they released it with a free 
>> license for both VAX and Alpha (and Itanium), but it was far too late 
>> for most people to have any interest in adopting it. I still do some 
>> BLISS coding, but I'm one of the few that I know of still doing it.
> In fact, when Digital announced the free licensing for BLISS-32 and BLISS-16,
> I immediately got in touch with our contact within Digital (help me out, Tim,
> what was Dick's last name?  the guy who helped XKL get the 36-bit stuff and
> introduced you and me in Marlboro) about getting BLISS-36 released the same
> way.  There may not have been a large market for it, but I wanted to make sure
> that XKL's customers had access if they wanted it.
Dick Greeley.  Former product manager in HPS, by then in the corporate
licensing group.
> Rich
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Rich Alderson]

> Date: Fri, 26 Jan 2018 14:35:18 -0600
> From: Hunter Goatley 

> On 1/26/2018 2:22 PM, Timothe Litt wrote:

>> BLISS would have done better in the outside world, except for the 
>> DECision to price it higher than the market would bear.

> Indeed! I was fortunate to get access to BLISS in college thanks to 
> DEC's CSLG program, but it was their second-most expensive compiler 
> license (after Ada), so virtually no one outside of DEC used it. When 
> they originally released Alpha, they weren't planning to make the BLISS 
> compiler available, but I and others worked to try to get DEC to change 
> that. As I'm sure you know, in the end, they released it with a free 
> license for both VAX and Alpha (and Itanium), but it was far too late 
> for most people to have any interest in adopting it. I still do some 
> BLISS coding, but I'm one of the few that I know of still doing it.

In fact, when Digital announced the free licensing for BLISS-32 and BLISS-16,
I immediately got in touch with our contact within Digital (help me out, Tim,
what was Dick's last name?  the guy who helped XKL get the 36-bit stuff and
introduced you and me in Marlboro) about getting BLISS-36 released the same
way.  There may not have been a large market for it, but I wanted to make sure
that XKL's customers had access if they wanted it.

Rich
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Hunter Goatley]

On 1/26/2018 2:22 PM, Timothe Litt wrote:


BLISS would have done better in the outside world, except for the 
DECision to price it higher than the market would bear.


Indeed! I was fortunate to get access to BLISS in college thanks to 
DEC's CSLG program, but it was their second-most expensive compiler 
license (after Ada), so virtually no one outside of DEC used it. When 
they originally released Alpha, they weren't planning to make the BLISS 
compiler available, but I and others worked to try to get DEC to change 
that. As I'm sure you know, in the end, they released it with a free 
license for both VAX and Alpha (and Itanium), but it was far too late 
for most people to have any interest in adopting it. I still do some 
BLISS coding, but I'm one of the few that I know of still doing it.


--
Hunter
--
Hunter Goatley, Process Software, http://www.process.com/
goathun...@goatley.com   http://hunter.goatley.com/

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Timothe Litt]

On 26-Jan-18 15:12, Johnny Billquist wrote:
> On 2018-01-26 20:26, Clem Cole wrote:
>>
>>
>> On Fri, Jan 26, 2018 at 2:09 PM, Johnny Billquist > > wrote:
>>
>>
>>     Right. As far as I know, BLISS-16 only ran under VMS.
>>
>> Hmm I'd be careful here.   As I understand it,​ Hobbs has implied
>> they did the work on the 10 to start with because at the time TLG was
>> using PDP-10s.   As one of the language designers, I'd believe him. 
>> That said, what saw the light of day as product I can not say, I was
>> not paying attention to that in those days.   Phil or Tim might know.
>
> Looked around some more, and it seems both BLISS-16 and BLISS-32 could
> be run under the PDP-10. Oh well. Never seen or heard about that in
> real life, but I guess it must have existed at one point then.
>
I used both in real life. 

I don't believe either was released externally.

BLISS would have done better in the outside world, except for the
DECision to price it higher than the market would bear.

> Johnny
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Johnny Billquist]

On 2018-01-26 20:38, Clem Cole wrote:



On Fri, Jan 26, 2018 at 2:17 PM, Johnny Billquist > wrote:



I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've
never seen or heard anything about BLISS-16 running on Alpha or beyond. 


​Gem did exactly that conceptually.​


Wasn't/isn't GEM the compiler core used for most languages later on? I 
didn't think BLISS itself was using GEM, but I don't know at all. 
However, I believe/assume/think I heard that GEM itself is written in BLISS.



I guess it could be possible to do, but I sortof doubt anyone did.

​It's a testing problem.   DEC was not only doing emergency fixes ​for 
the PDP-11 by the time of Alpha, so I agree.   I don't think TLG did 
anything with the EOL systems by then, they had their hands full with 
Vax, Alpha and 386; plus all the front ends.


When the Alpha came out, the PDP-11 was not dead. But I would not expect 
that much work was done anymore. They had tools and products, which they 
continued to use and improve. But moving to a new platform for any of it 
would have been very doubtful.



If anyone have the bits, I would be very interested in hearing about
it, as I would like to recompile some bits and pieces. (Any BLISS-16
compiler would be a good start.)

​VMSinc had the Gem compiler as part of their license.   As I say, they 
have Neil hacking on it again.   But I believe that he is only worried 
about Itanium and INTEL*64 at the moment.​  I also do not know what they 
are doing with the front-ends.   Clearly, they are working with the 
BLISS front-end, but I have not idea what HP has them doing for the 
other languages.  I would expect to see C/C++/Fortran brought forward at 
least through the dialect that DEC/Compaq/HP had at EOL, so customer 
code will recompile, since I know of OVMS code in those three languages.


Yes, BLISS is being worked on, as is GEM. I saw some comment by on the 
progress and issues around this from some VSI person not long ago.

But all that is far removed from anything PDP-11 related.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Johnny Billquist]

On 2018-01-26 20:26, Clem Cole wrote:



On Fri, Jan 26, 2018 at 2:09 PM, Johnny Billquist > wrote:



Right. As far as I know, BLISS-16 only ran under VMS.

Hmm I'd be careful here.   As I understand it,​ Hobbs has implied they 
did the work on the 10 to start with because at the time TLG was using 
PDP-10s.   As one of the language designers, I'd believe him.  That 
said, what saw the light of day as product I can not say, I was not 
paying attention to that in those days.   Phil or Tim might know.


Looked around some more, and it seems both BLISS-16 and BLISS-32 could 
be run under the PDP-10. Oh well. Never seen or heard about that in real 
life, but I guess it must have existed at one point then.


Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Paul Koning]

> On Jan 26, 2018, at 2:38 PM, Clem Cole  wrote:
> 
> ...
> ​VMSinc had the Gem compiler as part of their license.   As I say, they have 
> Neil hacking on it again.   But I believe that he is only worried about 
> Itanium and INTEL*64 at the moment.​  I also do not know what they are doing 
> with the front-ends.  

One of the more curious front ends of GEM is the Alpha assembler.  I found out 
about that when doing some Alpha hand-optimizing early on (a handcoded "memcpy 
with TCP checksum calculation while doing it" if I remember right).  It turned 
out I could write drafts of that code and give it to the assembler with a 
/OPTIMIZE switch to let the back end take what I wrote and do stuff to it.  It 
wasn't always right, but it was a neat source of ideas.

The only other optimizing assembler I can think of is SOAP, way back in the 
1950s.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 2:17 PM, Johnny Billquist  wrote:
>
>
> I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never
> seen or heard anything about BLISS-16 running on Alpha or beyond.

​Gem did exactly that conceptually.​



> I guess it could be possible to do, but I sortof doubt anyone did.

​It's a testing problem.   DEC was not only doing emergency fixes ​for the
PDP-11 by the time of Alpha, so I agree.   I don't think TLG did anything
with the EOL systems by then, they had their hands full with Vax, Alpha and
386; plus all the front ends.




> If anyone have the bits, I would be very interested in hearing about it,
> as I would like to recompile some bits and pieces. (Any BLISS-16 compiler
> would be a good start.)

​VMSinc had the Gem compiler as part of their license.   As I say, they
have Neil hacking on it again.   But I believe that he is only worried
about Itanium and INTEL*64 at the moment.​  I also do not know what they
are doing with the front-ends.   Clearly, they are working with the BLISS
front-end, but I have not idea what HP has them doing for the other
languages.  I would expect to see C/C++/Fortran brought forward at least
through the dialect that DEC/Compaq/HP had at EOL, so customer code will
recompile, since I know of OVMS code in those three languages.

Clem
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Clem Cole]

On Fri, Jan 26, 2018 at 2:09 PM, Johnny Billquist  wrote:

>
> Right. As far as I know, BLISS-16 only ran under VMS.

Hmm I'd be careful here.   As I understand it,​ Hobbs has implied they did
the work on the 10 to start with because at the time TLG was using PDP-10s.
  As one of the language designers, I'd believe him.  That said, what saw
the light of day as product I can not say, I was not paying attention to
that in those days.   Phil or Tim might know.

BTW -- fun side story, the BLISS "code comment" (C Pragmas if you will for
folks that don't speak a dead language) you will see in some old CMU system
code for C.mmp and Cm* is marked 'BOH'  -- which means 'Buzz-Off-Hobbs'
telling him to turn his damned optimizer and listen to us kernel guys.
ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Johnny Billquist]

On 2018-01-26 18:48, Timothe Litt wrote:
BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS - 
evolved (and greatly extended) from BLISS-11, but not (really) 
source-compatible for non-trivial programs.  "common" means that (with 
carefully defined exceptions that can be conditionally compiled), the 
same language is accepted by all, and it's possible to write portable 
programs.  Including common BLISS itself.  RMS-10/20 is another 
non-trivial example - same sources as VAX/RMS.  There are a number of 
targets and host environment combinations that are supported.


BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object 
code.  I used both.  I didn't encounter an Alpha-hosted version - but it 
should have compiled & run there, so it probably existed.  Or was VESTed.


I don't think BLISS-16 ran on PDP-10, but I could be wrong. I've never 
seen or heard anything about BLISS-16 running on Alpha or beyond. I 
guess it could be possible to do, but I sortof doubt anyone did. If 
anyone have the bits, I would be very interested in hearing about it, as 
I would like to recompile some bits and pieces. (Any BLISS-16 compiler 
would be a good start.)



Most software written in BLISS-10 & -11 was converted to common  BLISS.

There was an attempt at self-hosting BLISS-16, but it failed - 
technically, it ran, but there really wasn't enough address space to 
make it usable.  Cross-compiling wasn't popular (networks were crude), 
so BLISS-16 was not as widely adopted.


Well, parts of the RSX kernel is written in BLISS-16, and all of RMS-11. 
Also some parts of DECnet-11M-PLUS.

That much I know. I don't know what else might been written in BLISS-16.

Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Clem Cole]

On Fri, Jan 26, 2018 at 12:48 PM, Timothe Litt  wrote:

> I wrote a fair bit of BLISS at various stages of its evolution.  My
> recollection is:
>
> BLISS-10 & BLISS-11 came from Wulf & Co at CMU.  BLISS-10 is self-hosted
>
​Right - Wulf, Steve Hobbs et al,  FWIW: I just had lunch with Steve a few
minutes ago.​

> .
>
> BLISS-11 is an evolution of BLISS-10.  There was a PDP10-hosted version of
> BLISS-11.  I don't think it was ported to VAX.
>
> BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS -
> evolved (and greatly extended) from BLISS-11, but not (really)
> source-compatible for non-trivial programs.  "common" means that (with
> carefully defined exceptions that can be conditionally compiled), the same
> language is accepted by all, and it's possible to write portable programs.
> Including common BLISS itself.  RMS-10/20 is another non-trivial example -
> same sources as VAX/RMS.  There are a number of targets and host
> environment combinations that are supported.
>
> BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object code.
> I used both.  I didn't encounter an Alpha-hosted version - but it should
> have compiled & run there, so it probably existed.  Or was VESTed.
>
> Most software written in BLISS-10 & -11 was converted to common  BLISS.
>
> There was an attempt at self-hosting BLISS-16, but it failed -
> technically, it ran, but there really wasn't enough address space to make
> it usable.  Cross-compiling wasn't popular (networks were crude), so
> BLISS-16 was not as widely adopted.
>

​This follows my recollection/understanding with the minor tweak of
addition being BLISS-INTEL64 (not to be confused with IA64), which is what
the VMS, Inc for using now for the new OVMS port to Intel*64 systems.   I
believe that is currently running on an Alpha and cross-compiling, but Neil
Faiman (one of the authors) was not at the usual 'compiler group Friday
lunch' today to ask.  Last I knew it was not 100% self hosting, although I
think Neil has also said he had the development running on his Mac.   So he
may be cross compiling from a Mac not OVMS/Alpha - which would all testing
on his laptop.   (I've sent him email to make sure and if I'm miss-informed
I'll update).

The other thing to add is there were at least two generations of the
compilers within DEC that I knew about.  Tim you may have know of a third
when I was off doing other things.   The last (current) is the 'Gem'
compilers which was a rewrite to allow N font-ends, with Y back-ends.   I
thought 'Compatible BLISS' was done to create BLISS-36/16/32 (PDP-10, 11,
Vax) from the original CMU base; but was only targeting BLISS.   AFAIK, the
original Compatible BLISS compiler was developed on the PDP-10 and
eventually replaced the CMU code.  Prism forced the rewrite of the
back-ends and with it the later generation and TLG wanted to clean up its
act with a single back-end/optimizer that was common for all the languages
[hence the Gem project - I'd have to ask Rich Grove for the details].
IIRC, Vax was used as the base for that system, although it moved to Alpha
by the mid/late 1990s.

Clem

ᐧ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Johnny Billquist]

On 2018-01-26 18:08, Phil Budne wrote:

Paul Koning wrote:

As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
the other was built at DEC.  Both are cross-compilers, but I don't remember 
which platform.  PDP-10 for both?  10 for one and VAX for the other?


BLISS-11 was written in BLISS-10 (and both were written at C-MU), and
BLISS-11 was the jumping off point for COMMON BLISS.  I think sources
for both 'B10 and 'B11 are on PDP-10 DECUS tapes.


Hmm, the sources could be fun to check.


BLISS-16 was a member of the COMMON BLISS family.  I don't ever
remember seeing an EXE for it on a PDP-10, but I was never a COMMON
BLISS fan.  I hacked on FINE at Stevens Tech (the computing center had
a copy of BLISS-36, the PDP-10 COMMON BLISS compiler, but it wasn't
available to the unwashed masses).  When I went to DEC, I worked on
FORTRAN-10/20, which was also in BLISS-10.  I was down in Marlborough
(MR1-2) and don't recall ever seeing COMMON BLISS sources.


Right. As far as I know, BLISS-16 only ran under VMS.


I do recall a mention (perhaps in a published article?) of the
existence of a "cut down" version of BLISS-16 that could run on an '11.


That would be uBLISS (or Micro BLISS). As far as I know/heard, it got as 
far as working, but it was abandoned as people decided it would not ever 
become good enough to actually be used for any development.

I have a manual/documentation for uBLISS, but nothing of the actual code.


I once sang in a chorus with someone who had worked on COMMON BLISS.
ISTR he said he was a contractor, not a DEC employee.

My boss on the F10 project was Sara Murphy, one of the original F10
developers, and I have some recall that she had been involved in a
fancy BASIC for TOPS-20 (I _think_ it was called BP2, but I could be
wrong).


Yes. That would be the BASIC+2 for TOPS-20. It's written in BLISS, and 
have nothing to do with the BASIC+2 for PDP-11. Except, I guess, that 
they tried to be compatible.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Timothe Litt]

On 26-Jan-18 11:37, Paul Koning wrote:
>
>> On Jan 25, 2018, at 8:15 PM, Clem Cole  wrote:
>>
>> ...
>> RSTS Basic is a late entry, the language support for it, originally came 
>> from the compiler group which again was originally PDP-10 based (also 
>> remember the PDP-11 BLISS compiler needed a 10 to run it).
> Are you talking about BASIC-PLUS-2?  RSTS BASIC-PLUS dates from 1970, and was 
> written under contract for DEC by Evans, Griffiths & Hart ("EGH").  It is 
> essentially a P-code compiler, to use terminology that didn't appear until 
> later; it doesn't generate any machine code.  And as far as I know, it is not 
> based on any BASIC implementation for any other system.
>
> As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
> the other was built at DEC.  Both are cross-compilers, but I don't remember 
> which platform.  PDP-10 for both?  10 for one and VAX for the other? 

I wrote a fair bit of BLISS at various stages of its evolution.  My
recollection is:

BLISS-10 & BLISS-11 came from Wulf & Co at CMU.  BLISS-10 is self-hosted.

BLISS-11 is an evolution of BLISS-10.  There was a PDP10-hosted version
of BLISS-11.  I don't think it was ported to VAX.

BLISS-36,-16,-32,-32E,-64E, MIPS, INTEL, IA64, are DEC's common BLISS -
evolved (and greatly extended) from BLISS-11, but not (really)
source-compatible for non-trivial programs.  "common" means that (with
carefully defined exceptions that can be conditionally compiled), the
same language is accepted by all, and it's possible to write portable
programs.  Including common BLISS itself.  RMS-10/20 is another
non-trivial example - same sources as VAX/RMS.  There are a number of
targets and host environment combinations that are supported.

BLISS-16 is hosted on both PDP-10 and VAX, producing PDP-11 object
code.  I used both.  I didn't encounter an Alpha-hosted version - but it
should have compiled & run there, so it probably existed.  Or was VESTed. 

Most software written in BLISS-10 & -11 was converted to common  BLISS.

There was an attempt at self-hosting BLISS-16, but it failed -
technically, it ran, but there really wasn't enough address space to
make it usable.  Cross-compiling wasn't popular (networks were crude),
so BLISS-16 was not as widely adopted.

For a more complete history, see
https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf



>   paul
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 26, 2018, at 12:08 PM, Phil Budne  wrote:
> 
> Paul Koning wrote:
>> As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
>> the other was built at DEC.  Both are cross-compilers, but I don't remember 
>> which platform.  PDP-10 for both?  10 for one and VAX for the other?
> 
> BLISS-11 was written in BLISS-10 (and both were written at C-MU), and
> BLISS-11 was the jumping off point for COMMON BLISS.  I think sources
> for both 'B10 and 'B11 are on PDP-10 DECUS tapes.

Thanks.  I've never used it, but I ran into it when looking at the CMU PDP-11 
ALGOL-68 implementation.  I had some DECtapes of that code, only the runtime 
library if I remember right.  They seem to have disappeared, and I don't know 
if that compiler has been preserved.  Note that ALGOL-68 is an entirely 
different language than ALGOL-60; in a number of areas it served as inspiration 
for C++.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Johnny Billquist]

Bliss-11 was for the pdp10. Bliss-16 was for VMS.
I believe it Bliss-11 that came from CMU.

  Johnny 


Paul Koning  skrev: (26 januari 2018 17:37:28 CET)
>
>
>> On Jan 25, 2018, at 8:15 PM, Clem Cole  wrote:
>> 
>> ...
>> RSTS Basic is a late entry, the language support for it, originally
>came from the compiler group which again was originally PDP-10 based
>(also remember the PDP-11 BLISS compiler needed a 10 to run it).
>
>Are you talking about BASIC-PLUS-2?  RSTS BASIC-PLUS dates from 1970,
>and was written under contract for DEC by Evans, Griffiths & Hart
>("EGH").  It is essentially a P-code compiler, to use terminology that
>didn't appear until later; it doesn't generate any machine code.  And
>as far as I know, it is not based on any BASIC implementation for any
>other system.
>
>As for BLISS, there's BLISS-16 and BLISS-11.  One came from
>Carnegie-Mellon; the other was built at DEC.  Both are cross-compilers,
>but I don't remember which platform.  PDP-10 for both?  10 for one and
>VAX for the other? 
>
>   paul

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Heh. As a reference. I'm running an RSX system on simh with four 8G disks. No 
point in being cheap here.

  Johnny 


Zane Healy  skrev: (26 januari 2018 16:53:11 CET)
>Yes, I’m trying to preserve the data on hard drive from future hardware
>failures.
>
>I started out looking to backup to virtual tape.  I’m still looking to
>do that, but I’m now mainly looking to move the majority of the data
>off of the Physical Alpha, and to a Virtual VAX.  I hadn’t realized how
>big of virtual disks could be attached, so didn’t consider that a
>practical option.
>
>Last night I installed Linux on an old Core i5 system I’d picked up
>recently to run SIMH on.  Today I’ll try to get a new VAX system added
>to my cluster.  Unlike my other two virtual VAXen, this one is on a
>host with a 500GB drive (tiny by todays standards, but huge compared to
>the Alpha, or  where the other two virtual VAXen are running).
>
>Zane
>
>
>
>
>> On Jan 26, 2018, at 1:27 AM, Johnny Billquist  wrote:
>> 
>> Then I must have misunderstood the usecase. I thought you were
>looking at preserving a bunch of tapes from a future failure of the
>hardware.
>> 
>> Are you then looking at ways to perform backups of a physical system
>to virtual tape?
>> 
>> I would probably give the virtual machine a really big disk and run
>backup to that remote disk and not try to play with remote tapes.
>> 
>> Johnny 
>> 
>> 
>> Zane Healy  skrev: (26 januari 2018 02:54:20
>CET)
>> If it was applicable to the situation, then VMSTPC would work great. 
>It’s already installed on my Alpha, and I’m pretty sure there is a VAX
>binary for it in the VAX directory on there.  I also have it installed
>on my RSX-11M+.  It’s definitely a great tool.  Just not for this. :-)
>> 
>> Zane
>> 
>> 
>>  On Jan 25, 2018, at 2:54 PM, Armistead, Jason
> wrote:
>>  
>>  Zane
>>  
>>  The program that Johnny is thinking of is VMSPTC
>>  
>>  http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c
>
>>  
>>  Note sure if this is the latest, but it came up in the first set of
>Google search results for "VMSTPC"
>>  
>>  Good luck
>>  Jason
>>  
>>  
>>  -Original Message-
>>  From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of
>Johnny Billquist
>>  Sent: Thursday, 25 January 2018 5:48 PM
>>  To: Zane Healy; Tim Shoppa
>>  Cc: simh@trailing-edge.com
>>  Subject: Re: [Simh] VAX Tape Emulation?
>>  
>>  Zane - unless I remember wrong, there is a tool from DECUS to copy
>tapes to a file image, and then get that back to a tape again. The RSX
>version is called TPC, and I'm pretty sure it also exists for VMS.
>>  
>>  Using that, pull your physical tapes into files, copy the files over
>to the simulated machines, and write them back out to simulated tapes
>there.
>>  
>>Johnny
>> 
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>> -- 
>> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Phil Budne]

Paul Koning wrote:
> As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
> the other was built at DEC.  Both are cross-compilers, but I don't remember 
> which platform.  PDP-10 for both?  10 for one and VAX for the other?

BLISS-11 was written in BLISS-10 (and both were written at C-MU), and
BLISS-11 was the jumping off point for COMMON BLISS.  I think sources
for both 'B10 and 'B11 are on PDP-10 DECUS tapes.

BLISS-16 was a member of the COMMON BLISS family.  I don't ever
remember seeing an EXE for it on a PDP-10, but I was never a COMMON
BLISS fan.  I hacked on FINE at Stevens Tech (the computing center had
a copy of BLISS-36, the PDP-10 COMMON BLISS compiler, but it wasn't
available to the unwashed masses).  When I went to DEC, I worked on
FORTRAN-10/20, which was also in BLISS-10.  I was down in Marlborough
(MR1-2) and don't recall ever seeing COMMON BLISS sources.

I do recall a mention (perhaps in a published article?) of the
existence of a "cut down" version of BLISS-16 that could run on an '11.

I once sang in a chorus with someone who had worked on COMMON BLISS.
ISTR he said he was a contractor, not a DEC employee.

My boss on the F10 project was Sara Murphy, one of the original F10
developers, and I have some recall that she had been involved in a
fancy BASIC for TOPS-20 (I _think_ it was called BP2, but I could be
wrong).

phil
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 25, 2018, at 8:15 PM, Clem Cole  wrote:
> 
> ...
> RSTS Basic is a late entry, the language support for it, originally came from 
> the compiler group which again was originally PDP-10 based (also remember the 
> PDP-11 BLISS compiler needed a 10 to run it).

Are you talking about BASIC-PLUS-2?  RSTS BASIC-PLUS dates from 1970, and was 
written under contract for DEC by Evans, Griffiths & Hart ("EGH").  It is 
essentially a P-code compiler, to use terminology that didn't appear until 
later; it doesn't generate any machine code.  And as far as I know, it is not 
based on any BASIC implementation for any other system.

As for BLISS, there's BLISS-16 and BLISS-11.  One came from Carnegie-Mellon; 
the other was built at DEC.  Both are cross-compilers, but I don't remember 
which platform.  PDP-10 for both?  10 for one and VAX for the other? 

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 25, 2018, at 7:23 PM, Johnny Billquist  wrote:
> 
> On 2018-01-26 01:03, Tony Nicholson wrote:
>> Definitely BASIC-Plus on RSTS!  You may need to replace the “&” with “PRINT” 
>> in some of the files.
> 
> Which should tell you that it's not for BASIC+ on RSTS/E. :-)
> Also, : for separating statements is, as far as I remember, also not in 
> BASIC+, which instead uses \, just like BASIC+2.

Not true.  BASIC-PLUS, at least starting with RSTS V5 or thereabouts, 
*supports* BP2 syntax as an alternate option.  But it does not insist on it and 
it still supports the old syntax as well.  Here is RSTS V10.1:

list
BPTEST  11:30 AM26-Jan-18
10 & "hi there" :
   & "line 2, with  continuation"
20 end

Ready

run
BPTEST  11:30 AM26-Jan-18
hi there
line 2, with  continuation

Ready

For BP2, & as shorthand for PRINT is not allowed, : must be replaced by \, and 
continuation lines must be & rather than .  If you do that, the file 
will still work with BASIC-PLUS in RSTS/E (but not on V4A).

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 25, 2018, at 6:44 PM, Johnny Billquist  wrote:
> 
> Cool. Thanks. Downloaded and unpacket.
> Anyone interested and on HECnet can now find them on MIM::DU:[101GAMES]
> 
> Looked a little at one or two files. BASIC+2 do not like them. The code uses 
> special shorts, functions and specifics that don't match.
> I wonder if BASIC+ accepts them either, or if this might be from some other 
> BASIC dialect that DEC had at some point.
> 
> If I have plenty of time at some point, I might sit down and write a 
> converter for them to BASIC+2 style.

There is a converter to do that for RSTS, I believe it was included as a 
standard tool.  Can't remember the name.  The line ending conventions can be 
done by running it through TECO (read with /B+ and save with /B2).  But other 
details, like the use of colon rather than backslash as statement separator 
you'll have to do by hand.

BASIC-PLUS and BASIC-PLUS-2 are different languages.  It's not hard to write a 
program acceptable to both, but source text that predates the release of 
BASIC-PLUS-2 are likely to need work.  And sufficiently old ones (like ones 
written for RSTS V4A) definitely will, because in those version, BASIC-PLUS did 
not yet support the -2 compatible syntax.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Zane Healy]

Yes, I’m trying to preserve the data on hard drive from future hardware 
failures.

I started out looking to backup to virtual tape.  I’m still looking to do that, 
but I’m now mainly looking to move the majority of the data off of the Physical 
Alpha, and to a Virtual VAX.  I hadn’t realized how big of virtual disks could 
be attached, so didn’t consider that a practical option.

Last night I installed Linux on an old Core i5 system I’d picked up recently to 
run SIMH on.  Today I’ll try to get a new VAX system added to my cluster.  
Unlike my other two virtual VAXen, this one is on a host with a 500GB drive 
(tiny by todays standards, but huge compared to the Alpha, or  where the other 
two virtual VAXen are running).

Zane




> On Jan 26, 2018, at 1:27 AM, Johnny Billquist  wrote:
> 
> Then I must have misunderstood the usecase. I thought you were looking at 
> preserving a bunch of tapes from a future failure of the hardware.
> 
> Are you then looking at ways to perform backups of a physical system to 
> virtual tape?
> 
> I would probably give the virtual machine a really big disk and run backup to 
> that remote disk and not try to play with remote tapes.
> 
> Johnny 
> 
> 
> Zane Healy  skrev: (26 januari 2018 02:54:20 CET)
> If it was applicable to the situation, then VMSTPC would work great.  It’s 
> already installed on my Alpha, and I’m pretty sure there is a VAX binary for 
> it in the VAX directory on there.  I also have it installed on my RSX-11M+.  
> It’s definitely a great tool.  Just not for this. :-)
> 
> Zane
> 
> 
>  On Jan 25, 2018, at 2:54 PM, Armistead, Jason  
> wrote:
>  
>  Zane
>  
>  The program that Johnny is thinking of is VMSPTC
>  
>  http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c 
> 
>  
>  Note sure if this is the latest, but it came up in the first set of Google 
> search results for "VMSTPC"
>  
>  Good luck
>  Jason
>  
>  
>  -Original Message-
>  From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny 
> Billquist
>  Sent: Thursday, 25 January 2018 5:48 PM
>  To: Zane Healy; Tim Shoppa
>  Cc: simh@trailing-edge.com
>  Subject: Re: [Simh] VAX Tape Emulation?
>  
>  Zane - unless I remember wrong, there is a tool from DECUS to copy tapes to 
> a file image, and then get that back to a tape again. The RSX version is 
> called TPC, and I'm pretty sure it also exists for VMS.
>  
>  Using that, pull your physical tapes into files, copy the files over to the 
> simulated machines, and write them back out to simulated tapes there.
>  
>Johnny
> 
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh 
> 
> -- 
> Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Paul Koning]

That sounds right.  Incidentally, I'm not sure how well known this is, but RSTS 
(with the "new BACKUP" introduced in V9.0) uses the VMS backup set format.  
That means you can use backup sets to interchange between the two, with some 
care because of the differences in file naming.

paul

> On Jan 25, 2018, at 9:11 PM, Larry Baker  wrote:
> 
> As far as I am aware, there is no limit, up to the amount of disk space 
> available.  Backup Save Sets are just RMS sequential files with fixed record 
> lengths (on disk, usually 32768 bytes, on tape, I think the default is 4096, 
> except 2048 for Interchange format).
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Terminal Emulator

[Armistead, Jason]

Another good terminal emulator was WRQ's Reflection 2.  Of course, it was not 
freeware/shareware, but it ran well, and had its own file transfer protocol 
built in.  For VAX/VMS hosts, once you uploaded a minimalist bootstrap program 
(a simple copy-paste operation of a DCL script that embedded some VAX MACRO 
code that it assembled IIRC), it then copied an actual VAX EXE that could do 
the heavy lifting of file upload/download long-term. Worked very well and we 
were loyal Reflection users all the way through from DOS 3.x in the late 1980s 
through to the days of Windows 2000 (circa Reflection V7.x for Windows IIRC).  
Nowadays the Reflection suite is owned by MicroFocus.

Fun times ...

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Richard
Sent: Friday, 26 January 2018 1:15 AM
To: SIMH
Subject: Re: [Simh] Terminal Emulator

I used PROCOMM on an 8088; I never used telix.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX Tape Emulation?

[Johnny Billquist]

Then I must have misunderstood the usecase. I thought you were looking at 
preserving a bunch of tapes from a future failure of the hardware.

Are you then looking at ways to perform backups of a physical system to virtual 
tape?

I would probably give the virtual machine a really big disk and run backup to 
that remote disk and not try to play with remote tapes.

  Johnny 


Zane Healy  skrev: (26 januari 2018 02:54:20 CET)
>If it was applicable to the situation, then VMSTPC would work great. 
>It’s already installed on my Alpha, and I’m pretty sure there is a VAX
>binary for it in the VAX directory on there.  I also have it installed
>on my RSX-11M+.  It’s definitely a great tool.  Just not for this. :-)
>
>Zane
>
>
>> On Jan 25, 2018, at 2:54 PM, Armistead, Jason
> wrote:
>> 
>> Zane
>> 
>> The program that Johnny is thinking of is VMSPTC
>> 
>> http://www.digiater.nl/openvms/decus/vax86a/bnelson/vmstpc/vmstpc.c
>> 
>> Note sure if this is the latest, but it came up in the first set of
>Google search results for "VMSTPC"
>> 
>> Good luck
>> Jason
>> 
>> 
>> -Original Message-
>> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of
>Johnny Billquist
>> Sent: Thursday, 25 January 2018 5:48 PM
>> To: Zane Healy; Tim Shoppa
>> Cc: simh@trailing-edge.com
>> Subject: Re: [Simh] VAX Tape Emulation?
>> 
>> Zane - unless I remember wrong, there is a tool from DECUS to copy
>tapes to a file image, and then get that back to a tape again. The RSX
>version is called TPC, and I'm pretty sure it also exists for VMS.
>> 
>> Using that, pull your physical tapes into files, copy the files over
>to the simulated machines, and write them back out to simulated tapes
>there.
>> 
>>   Johnny
>___
>Simh mailing list
>Simh@trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 168, Issue 38

[Johnny Billquist]

It's not really a bug. It's a limitation. A bit unfortunate, but a design 
choice made by the proframmer who wrote the firmware.

  Johnny 


khandy21yo  skrev: (26 januari 2018 03:35:24 CET)
>The MicroVAX 3100 had a bug in the boot Rom that limited it to a 1.06?
>Disk. I don't know if it also occurred on other systems.
>
>
>Sent from my Galaxy Tab® A
> Original message From: Larry Baker 
>Date: 1/25/18  7:17 PM  (GMT-07:00) To: heal...@avanthar.com Cc: SIMH
> Subject: Re: [Simh] Simh Digest, Vol 168,
>Issue 38 
>We ran into this on a real VAX when we added a 20GB SCSI disk, as I
>recall.  Either VAX/VMS or the hardware (I think it was VAX/VMS) only
>looks at the low-order 24 bits of the disk size.  So, our 20GB disk was
>viewed as a 3+GB drive on the VAX.  Alpha/VMS has no problem handling
>larger drives.  I think I've used 100GB drives on an Alpha.  I know I
>have a 72GB and a 50GB drive on our Alpha now.
>
>Larry Baker
>US Geological Survey
>650-329-5608
>ba...@usgs.gov
>
>
>
>
>
>
>On 25 Jan 2018, at 6:04:06 PM, simh-requ...@trailing-edge.com wrote:
>Message: 3
>Date: Thu, 25 Jan 2018 18:01:41 -0800
>From: Zane Healy 
>To: Dennis Boone 
>Cc: simh 
>Subject: Re: [Simh] VAX Tape Emulation?
>Message-ID: 
>Content-Type: text/plain; charset=utf-8
>
>
>On Jan 25, 2018, at 2:22 PM, Dennis Boone  wrote:
>
>If you're venturing into unix technology, it's possible to mount nfs
>shares on the VMS machines.  Then you can use BACKUP to write save sets
>onto the nfs share.  There seems to be some care needed with ADF
>metadata.  Multinet seems to write this to a hidden file or
>subdirectory; not sure what UCX/TCPIP do.
>
>I actually looked into this option around 2008 (for the same Alpha).
> If I remember correctly I ran into a problem on the VMS side of the
>file size limit (I have the same disk size now I had in 2008).  This
>can work, but you have to break larger disks up into chunks.  I’m
>hoping to avoid that, with the solution I’m looking at.
>
>Zane

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 168, Issue 38

[Johnny Billquist]

That is not solving the sctual problem.
And it's also unrelated to the 24 bit size for block numbers in VMS.

The boot issue is specific to some 3100 models and has to do with the scsi 
commands the boot prom uses. The driver in the boot prom uses group 0 commands, 
which only have a 21 bit field for block number. This leads to a 1G limit. This 
is only neede for booting and it actually only means that whatever is involved 
in the boot phase needs to be in the first 1G of the disk. If you can ensure 
that, then there is no problem having a larger disk even for booting. Unix with 
its partitioning of the disk can easily guarantee this for example. Once the 
system have booted the device driver in the boot prom is not used anyway so 
then the limit does not apply anymore.

The second issue is the 24 bit block number. This is a parameter setup when the 
file system is initialized and is the size of retrieval pointers. ODS1 pretty 
much only supports 24 bit retrieval pointers, but ODS2 can also have 32 bit 
retrieval pointers. But it has to be decided at file system initialization, and 
cannot be changed afterwards.

  Johnny 


Bob Eager  skrev: (26 januari 2018 09:49:46 CET)
>I know I've hacked larger SCSI disks in the past, for the 3100. I made
>them report a smaller size so that they would boot.
>
>On Thu, 25 Jan 2018 19:35:24 -0700
>khandy21yo  wrote:
>
>> The MicroVAX 3100 had a bug in the boot Rom that limited it to a
>> 1.06? Disk. I don't know if it also occurred on other systems.
>> 
>> 
>> Sent from my Galaxy Tab® A
>>  Original message From: Larry Baker 
>> Date: 1/25/18  7:17 PM  (GMT-07:00) To: heal...@avanthar.com Cc: SIMH
>>  Subject: Re: [Simh] Simh Digest, Vol 168,
>> Issue 38 We ran into this on a real VAX when we added a 20GB SCSI
>> disk, as I recall.  Either VAX/VMS or the hardware (I think it was
>> VAX/VMS) only looks at the low-order 24 bits of the disk size.  So,
>> our 20GB disk was viewed as a 3+GB drive on the VAX.  Alpha/VMS has
>> no problem handling larger drives.  I think I've used 100GB drives on
>> an Alpha.  I know I have a 72GB and a 50GB drive on our Alpha now.
>> 
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> ba...@usgs.gov
>> 
>> 
>> 
>> 
>> 
>> 
>> On 25 Jan 2018, at 6:04:06 PM, simh-requ...@trailing-edge.com wrote:
>> Message: 3
>> Date: Thu, 25 Jan 2018 18:01:41 -0800
>> From: Zane Healy 
>> To: Dennis Boone 
>> Cc: simh 
>> Subject: Re: [Simh] VAX Tape Emulation?
>> Message-ID: 
>> Content-Type: text/plain; charset=utf-8
>> 
>> 
>> On Jan 25, 2018, at 2:22 PM, Dennis Boone  wrote:
>> 
>> If you're venturing into unix technology, it's possible to mount nfs
>> shares on the VMS machines.  Then you can use BACKUP to write save
>> sets onto the nfs share.  There seems to be some care needed with ADF
>> metadata.  Multinet seems to write this to a hidden file or
>> subdirectory; not sure what UCX/TCPIP do.
>> 
>> I actually looked into this option around 2008 (for the same Alpha).
>>  If I remember correctly I ran into a problem on the VMS side of the
>> file size limit (I have the same disk size now I had in 2008).  This
>> can work, but you have to break larger disks up into chunks.  I?m
>> hoping to avoid that, with the solution I?m looking at.
>> 
>> Zane
>> 
>
>___
>Simh mailing list
>Simh@trailing-edge.com
>http://mailman.trailing-edge.com/mailman/listinfo/simh

-- 
Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet.___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 168, Issue 38

[Bob Eager]

I know I've hacked larger SCSI disks in the past, for the 3100. I made
them report a smaller size so that they would boot.

On Thu, 25 Jan 2018 19:35:24 -0700
khandy21yo  wrote:

> The MicroVAX 3100 had a bug in the boot Rom that limited it to a
> 1.06? Disk. I don't know if it also occurred on other systems.
> 
> 
> Sent from my Galaxy Tab® A
>  Original message From: Larry Baker 
> Date: 1/25/18  7:17 PM  (GMT-07:00) To: heal...@avanthar.com Cc: SIMH
>  Subject: Re: [Simh] Simh Digest, Vol 168,
> Issue 38 We ran into this on a real VAX when we added a 20GB SCSI
> disk, as I recall.  Either VAX/VMS or the hardware (I think it was
> VAX/VMS) only looks at the low-order 24 bits of the disk size.  So,
> our 20GB disk was viewed as a 3+GB drive on the VAX.  Alpha/VMS has
> no problem handling larger drives.  I think I've used 100GB drives on
> an Alpha.  I know I have a 72GB and a 50GB drive on our Alpha now.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
> 
> 
> 
> On 25 Jan 2018, at 6:04:06 PM, simh-requ...@trailing-edge.com wrote:
> Message: 3
> Date: Thu, 25 Jan 2018 18:01:41 -0800
> From: Zane Healy 
> To: Dennis Boone 
> Cc: simh 
> Subject: Re: [Simh] VAX Tape Emulation?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
> 
> 
> On Jan 25, 2018, at 2:22 PM, Dennis Boone  wrote:
> 
> If you're venturing into unix technology, it's possible to mount nfs
> shares on the VMS machines.  Then you can use BACKUP to write save
> sets onto the nfs share.  There seems to be some care needed with ADF
> metadata.  Multinet seems to write this to a hidden file or
> subdirectory; not sure what UCX/TCPIP do.
> 
> I actually looked into this option around 2008 (for the same Alpha).
>  If I remember correctly I ran into a problem on the VMS side of the
> file size limit (I have the same disk size now I had in 2008).  This
> can work, but you have to break larger disks up into chunks.  I?m
> hoping to avoid that, with the solution I?m looking at.
> 
> Zane
> 

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh