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

[Timothe Litt]

On 28-Jan-18 18:38, Hunter Goatley wrote:
> On 1/28/2018 3:49 PM, Johnny Billquist wrote:
>
>> It's more or less a dead language, unless you are in a very specific
>> environment. So no, most likely it is not worth learning, if you are
>> thinking that you might work with it.
>
Agree.
> If you're writing code that's strictly for VMS and will never be used
> anywhere else, BLISS is a fine choice, if you're interested in
> learning it.
>
Agree.
>> Compared to C? Well, it is similar, I'd guess/say.
>
> BLISS-32 was designed as an operating systems language, so you can
> easily do things in BLISS that you can't do in C. On VAX, you could
> write subroutines that could be called via JSB instructions in MACRO,
> for example.
>
Generally agree.  But it's not a bright line.

IIRC, DECC added #pragma linkage for that.  But that only matters in
kernel code - any user mode JSB linkage  in the VAX calling standard has
a corresponding CALL linkage. 

But BLISS does it in the language proper; including allocating storage
in specific PSECTs.  And with its macros, it is much easier to do those
sorts of things portably.

The C language standard leaves a lot to the implementers' imagination -
or creative interpretation.  BLISS doesn't.

If I need to access device registers portably, I'll take BLISS over the
varying implementations of C's constant, readonly, and volatile.

> On the other hand, C has the C RTL. BLISS has no RTL, so be prepared
> for lots of calls to LIB$ and friends and system services.
>
Which are problematic/impossible in inner modes.  Then again, the C RTL
for inner modes is a late addition, and has restrictions.

You have to know your environment with either language. 

POSIX C provides a rich user-mode function library. 

BLISS requires that you provide your own.  But in the VMS environment,
that's done for you (see starlet.req, lib.req).  That's richer - but
hardly portable.   Then again, the only other targets are DEC/OSF1,
TOPS-10/20 & PDP-11s.  Which, except for this community, probably aren't
of interest.

If you stick with user mode, the details are different, but the
languages are roughly comparable (especially if you include the XPORT
library for BLISS).

It's all academic unless you are working in one of the supported
environments.

> Hunter



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 28-Jan-18 18:32, Clem Cole wrote:
>
>
> On Sun, Jan 28, 2018 at 4:43 PM, khandy21yo  > wrote:
>
>
> Never had BLISS on anything until long after it would have been
> useful. So how does BLISS compare to C as a systems programming
> language? Is it worth learning at this late date?
>
>
> ​I'll try to answer your questions in verse order - probably not worth
> learning; except for some education value and the ability to read and
> really understand any BLISS code you might come upon (if the later is
> something you really need/want to do).
>
> Armando Stetner, of the TIG (Telephone Industries Group in MKO) once
> made a set of 'BLISS is Ignorance' buttons which he gave to a lot of
> people (I still have mine).   While I loved the language, I loathed it
> too.  ​I'm in a interesting position here, because I learned BLISS
> before I learned C, since I was CMU type at the time and a student of
> Wulf and his wife.
>
> 40 years later, I've written way more C then BLISS.  But as Tim
> was saying there were some things about BLISS which I still miss -
> primarily the macro system and the way conditional compilation was
> handled.   It was much more sane that C's preprocessor; and the PDP-11
> optimizer (discussed in the Green Book) made the Ritchie C compiler
> see almost like a toy.
>
> Remember, part of there design of the language was with software
> engineering in mind.  Parnas et al was publishing and there was a lot
> of thought about what made for good programs.  Hence, no goto. 
> Similarly, it included a macro and conditional compilation system -
> which I think was something that really made BLISS and C much more
> useful than say PASCAL.    In fact, people wrote macro systems like m4
> and RATFOR so that PL/1 and FORTRAN could be conditionally compiled in
> a manner than was reasonable.  I've always said, for really SW
> engineering you need to have it (the problem with C/C++ is that it
> gets abused and some resulting code is worse because of it).
>
> The CMU BLISS compiler had one of my favorite errors of all time BTW.
>   You could use single letter like i, j, and k for loop variables, but
> if your real variable were less than 6 chars, you could get an
> 'unimaginative variable name' warning.  So for real system programs,
> expressions tended to actually have meaning and code was readable and
> easy to understand.
>
> BTW, like C, everything in BLISS is an expression and I think that
> worked well.  Also for the PDP-10 at least, it is had no language
> runtime (by the time of Alpha I think that was not wholly true).  
> There were a ton of associated libraries, but the compiler did
> everything.   C never really quite got to that because the Ritchie
> compiler was much smaller, so Dennis put a lot into the runtime under
> the covers.  Frankly, as a user since you are always using libraries,
> I never saw much of a difference.
>
> BLISS suffered one major design error (which was self inflicted and is
> an example of theory vs. practice) and a number of smaller ones that
> became sort of a death of thousand cuts.
>
> The big issue is the Wulf's choice of a 'store into' and 'contents of'
> operators vs. the traditional 'assignment' and C style pointer
> indirection.  His theory is 100% correct and it made the language much
> cleaner and >>once you understood it<<; much more regular.  C ended up
> with *, &, -> and a dot operator to handle different linguistic items.
>   BLISS is much more compact and from a >>compiler's writers
> standpoint<< mathematically explicit (which is what Bill was of
> course).  The idea was that if the language was consistent it make for
> better programs. The problem is that in practice, humans do not read
> code the same way as a compiler and the BLISS conventions take a lot
> of getting used to.   Plus if you are 'multi-lingual' your brain has
> to switch between the two schemes.   [Bill would later admit privately
> at least, it was great concept that in practice, just did not pan out].
>
> And finally, in the days of the old drum printers, if you ever look at
> printouts you will see a certain amount of 'bouncing' of text in a
> line, caused by the head solenoids firing a little early or late.  
> This means tops and bottoms of characters were often cut off and small
> symbols (like the period) might not be seen at all on the paper
> (although if you looked carefully you might see a small indentation
> from where is was supposed to have been -- I have examples of this
> effect in some old listings BTW).  We used to say, if your program did
> not work, get a pepper shaker and a sponge  then pour a few dots and
> remove a few others, and it would start to work ;-)
>
> On the smaller side, there were things like the N different exits.  
> IIRC Wulf used to say that was a bad idea and he should have supported
> labels and then allowed and 'exit' to got to a label.   The language
> took the Algol BEGIN/END 

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Timothe Litt]

On 28-Jan-18 18:29, Jeremy Begg wrote:
> Hi Timothe,
>
>>> Once you get SSH working you may find it's unusable.  On my RPi 3 it
>>> takes the VMS MultiNet SSH server several *minutes* to negotiate the
>>> SSL handshake.  I suspect (without having attempted any diagnosis!)
>>> that this is due to SIMH having to emulate a huge number of VAX floating
>>> point instructions.
>> I suggest running PCA to determine if this is in fact the cause.� Or
>> stop the emulation a few times while "hung" and look at the history buffer.
> Can you just clarify, what is "PCA"?  DEC Performance & Coverage Analyzer
> springs to mind but I'm not sure that's what you're referring to.
Yes.  A DECset tool.
> Thanks,
>
>   Jeremy Begg
>



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)

[Hunter Goatley]

On 1/28/2018 3:49 PM, Johnny Billquist wrote:

It's more or less a dead language, unless you are in a very specific 
environment. So no, most likely it is not worth learning, if you are 
thinking that you might work with it.


If you're writing code that's strictly for VMS and will never be used 
anywhere else, BLISS is a fine choice, if you're interested in learning it.



Compared to C? Well, it is similar, I'd guess/say.


BLISS-32 was designed as an operating systems language, so you can 
easily do things in BLISS that you can't do in C. On VAX, you could 
write subroutines that could be called via JSB instructions in MACRO, 
for example.


On the other hand, C has the C RTL. BLISS has no RTL, so be prepared for 
lots of calls to LIB$ and friends and system services.


Hunter


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

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Jeremy Begg]

Hi Timothe,

>> Once you get SSH working you may find it's unusable.  On my RPi 3 it
>> takes the VMS MultiNet SSH server several *minutes* to negotiate the
>> SSL handshake.  I suspect (without having attempted any diagnosis!)
>> that this is due to SIMH having to emulate a huge number of VAX floating
>> point instructions.
>I suggest running PCA to determine if this is in fact the cause.� Or
>stop the emulation a few times while "hung" and look at the history buffer.

Can you just clarify, what is "PCA"?  DEC Performance & Coverage Analyzer
springs to mind but I'm not sure that's what you're referring to.

Thanks,

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

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Timothe Litt]

On 28-Jan-18 18:04, Timothe Litt wrote:
>
> On 28-Jan-18 17:21, Jeremy Begg wrote:
>> Hi TIm,
>>
>>> ...
>>> Also I am figuring out how to set SSH2 terminal server. I successfully
>>> generated SSH2 keys on emulated SIMH VAX system.
>>> ...
>>> I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
>>> Armbian OS for 7/24 operation.
>> Once you get SSH working you may find it's unusable.  On my RPi 3 it
>> takes the VMS MultiNet SSH server several *minutes* to negotiate the
>> SSL handshake.  I suspect (without having attempted any diagnosis!)
>> that this is due to SIMH having to emulate a huge number of VAX floating
>> point instructions.
> I suggest running PCA to determine if this is in fact the cause.  Or
> stop the emulation a few times while "hung" and look at the history
> buffer.
>
> If I had to guess, I'd start by looking at where the required
> randomness (for key generation) is coming from.  In most
> implementations, that's the cause of typical hangs like these.  I
> don't know what Multinet is using for a source of randomness - perhaps
> Hunter can shed light on that.
>
> FP in SimH isn't that slow - the VAX format is unpacked, then integer
> (hardware) operations are performed on the "mantissa" and exponent,
> then the result repacked.  These are all integer operations, and
> should be reasonably fast on any processor, even a Pi.  The FP code
> would benefit from a high level of compiler optimization, as there are
> lots of opportunities for inlining.
>
> Note that the PI, and many modern CPUs provide a hardware source of
> randomness (which can be behind /dev/{u,}random).  It may be off by
> default, depending on your distribution.  I don't think that SimH VAX
> uses it, but it might be something to export.  Most older OS would try
> to gather randomness from device timing (interrupt jitter), something
> that SimH alters...  It can take quite a bit of data to get enough
> bits to satisfy randomness (or primality) tests used in key generation.
>
> Anyhow, FP would not be the first place I'd look.
>
>> (Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
>> minute to negotiate the SSL handshake, and of course the system would
>> "pause" every now and again while the session keys were renogotiated.
This supports the guess that the issue is more likely to be generating
random bits than the speed of FP emulation.

When I stopped paying attention to VMS, there was no hardware RNG
support.  The usual advice - MTH$RANDOM is a uniform software pseudo-RNG
that produces an F-float between 0.0 & 1.0.  It is fine for simulations
(as in statistics, not what SimH does), but not suitable for most
crypto.  Given the seed, the next number is predictable as it's a simple
congruential algorithm.  And there's no good way to initialize the seed
(for crypto).  Time, process ID, etc are guessable.  And these days, the
limited range of an F-Floating mantissa is susceptible to a dictionary. 

Things are actually more complicated than this summary, but the bottom
line is that if it is slow on hardware, it will be slow on SimH.  And
I'd look at what is happening during the hangs.  The root cause is
likely getting enough randomness...

>> I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
>> might improve, but they went dramatically backwards.)
>>
>> Regards
>>
>> Jeremy Begg
>>
>>   +-+
>>   |VSM Software Services Pty. Ltd.  |
>>   | http://www.vsm.com.au/  |
>>   |-|
>>   | P.O.Box 402, Walkerville, |  E-Mail:  jer...@vsm.com.au |
>>   | South Australia 5081  |   Phone:  +61 8 8221 5188   |
>>   |---|  Mobile:  0414 422 947  |
>>   |  A.C.N. 068 409 156   | FAX:  +61 8 8221 7199   |
>>   +-+
>>
>>



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)

[Clem Cole]

On Sun, Jan 28, 2018 at 4:43 PM, khandy21yo  wrote:

>
> Never had BLISS on anything until long after it would have been useful. So
> how does BLISS compare to C as a systems programming language? Is it worth
> learning at this late date?
>

​I'll try to answer your questions in verse order - probably not worth
learning; except for some education value and the ability to read and
really understand any BLISS code you might come upon (if the later is
something you really need/want to do).

Armando Stetner, of the TIG (Telephone Industries Group in MKO) once made a
set of 'BLISS is Ignorance' buttons which he gave to a lot of people (I
still have mine).   While I loved the language, I loathed it too.  ​I'm in
a interesting position here, because I learned BLISS before I learned C,
since I was CMU type at the time and a student of Wulf and his wife.

40 years later, I've written way more C then BLISS.  But as Tim was saying
there were some things about BLISS which I still miss - primarily the macro
system and the way conditional compilation was handled.   It was much more
sane that C's preprocessor; and the PDP-11 optimizer (discussed in the
Green Book) made the Ritchie C compiler see almost like a toy.

Remember, part of there design of the language was with software
engineering in mind.  Parnas et al was publishing and there was a lot of
thought about what made for good programs.  Hence, no goto.  Similarly, it
included a macro and conditional compilation system - which I think was
something that really made BLISS and C much more useful than say PASCAL.
 In fact, people wrote macro systems like m4 and RATFOR so that PL/1 and
FORTRAN could be conditionally compiled in a manner than was reasonable.
I've always said, for really SW engineering you need to have it (the
problem with C/C++ is that it gets abused and some resulting code is worse
because of it).

The CMU BLISS compiler had one of my favorite errors of all time BTW.   You
could use single letter like i, j, and k for loop variables, but if your
real variable were less than 6 chars, you could get an
'unimaginative variable name' warning.  So for real system programs,
expressions tended to actually have meaning and code was readable and easy
to understand.

BTW, like C, everything in BLISS is an expression and I think that worked
well.  Also for the PDP-10 at least, it is had no language runtime (by the
time of Alpha I think that was not wholly true).   There were a ton of
associated libraries, but the compiler did everything.   C never really
quite got to that because the Ritchie compiler was much smaller, so Dennis
put a lot into the runtime under the covers.  Frankly, as a user since
you are always using libraries, I never saw much of a difference.

BLISS suffered one major design error (which was self inflicted and is an
example of theory vs. practice) and a number of smaller ones that became
sort of a death of thousand cuts.

The big issue is the Wulf's choice of a 'store into' and 'contents of'
operators vs. the traditional 'assignment' and C style pointer
indirection.  His theory is 100% correct and it made the language much
cleaner and >>once you understood it<<; much more regular.  C ended up with
*, &, -> and a dot operator to handle different linguistic items.   BLISS
is much more compact and from a >>compiler's writers standpoint<<
mathematically explicit (which is what Bill was of course).  The idea was
that if the language was consistent it make for better programs. The
problem is that in practice, humans do not read code the same way as a
compiler and the BLISS conventions take a lot of getting used to.   Plus if
you are 'multi-lingual' your brain has to switch between the two schemes.
[Bill would later admit privately at least, it was great concept that in
practice, just did not pan out].

And finally, in the days of the old drum printers, if you ever look at
printouts you will see a certain amount of 'bouncing' of text in a line,
caused by the head solenoids firing a little early or late.   This means
tops and bottoms of characters were often cut off and small symbols (like
the period) might not be seen at all on the paper (although if you looked
carefully you might see a small indentation from where is was supposed to
have been -- I have examples of this effect in some old listings BTW).  We
used to say, if your program did not work, get a pepper shaker and a sponge
 then pour a few dots and remove a few others, and it would start to work
;-)

On the smaller side, there were things like the N different exits.   IIRC
Wulf used to say that was a bad idea and he should have supported labels
and then allowed and 'exit' to got to a label.   The language took the
Algol BEGIN/END and Algol68 idea of spelling word backwards to note the end
of a something (SET TES, NSET TESN ...).And of course because
the implementation of the language was done originally on the PDP-10 and
then later moved to create a PDP-11 target but 

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Timothe Litt]

On 28-Jan-18 17:21, Jeremy Begg wrote:
> Hi TIm,
>
>> ...
>> Also I am figuring out how to set SSH2 terminal server. I successfully
>> generated SSH2 keys on emulated SIMH VAX system.
>> ...
>> I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
>> Armbian OS for 7/24 operation.
> Once you get SSH working you may find it's unusable.  On my RPi 3 it
> takes the VMS MultiNet SSH server several *minutes* to negotiate the
> SSL handshake.  I suspect (without having attempted any diagnosis!)
> that this is due to SIMH having to emulate a huge number of VAX floating
> point instructions.
I suggest running PCA to determine if this is in fact the cause.  Or
stop the emulation a few times while "hung" and look at the history buffer.

If I had to guess, I'd start by looking at where the required randomness
(for key generation) is coming from.  In most implementations, that's
the cause of typical hangs like these.  I don't know what Multinet is
using for a source of randomness - perhaps Hunter can shed light on that.

FP in SimH isn't that slow - the VAX format is unpacked, then integer
(hardware) operations are performed on the "mantissa" and exponent, then
the result repacked.  These are all integer operations, and should be
reasonably fast on any processor, even a Pi.  The FP code would benefit
from a high level of compiler optimization, as there are lots of
opportunities for inlining.

Note that the PI, and many modern CPUs provide a hardware source of
randomness (which can be behind /dev/{u,}random).  It may be off by
default, depending on your distribution.  I don't think that SimH VAX
uses it, but it might be something to export.  Most older OS would try
to gather randomness from device timing (interrupt jitter), something
that SimH alters...  It can take quite a bit of data to get enough bits
to satisfy randomness (or primality) tests used in key generation.

Anyhow, FP would not be the first place I'd look.

> (Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
> minute to negotiate the SSL handshake, and of course the system would
> "pause" every now and again while the session keys were renogotiated.
> I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
> might improve, but they went dramatically backwards.)
>
> Regards
>
> Jeremy Begg
>
>   +-+
>   |VSM Software Services Pty. Ltd.  |
>   | http://www.vsm.com.au/  |
>   |-|
>   | P.O.Box 402, Walkerville, |  E-Mail:  jer...@vsm.com.au |
>   | South Australia 5081  |   Phone:  +61 8 8221 5188   |
>   |---|  Mobile:  0414 422 947  |
>   |  A.C.N. 068 409 156   | FAX:  +61 8 8221 7199   |
>   +-+
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh



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

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Jeremy Begg]

Hi TIm,

>...
>Also I am figuring out how to set SSH2 terminal server. I successfully
>generated SSH2 keys on emulated SIMH VAX system.
>...
>I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
>Armbian OS for 7/24 operation.

Once you get SSH working you may find it's unusable.  On my RPi 3 it
takes the VMS MultiNet SSH server several *minutes* to negotiate the
SSL handshake.  I suspect (without having attempted any diagnosis!)
that this is due to SIMH having to emulate a huge number of VAX floating
point instructions.

(Even on my real VAXstation 4000/96 the MultiNet SSH server took up to a
minute to negotiate the SSL handshake, and of course the system would
"pause" every now and again while the session keys were renogotiated.
I had hoped that in moving from a 100MHz VAX to a 1.2GHz SIMH VAX things
might improve, but they went dramatically backwards.)

Regards

Jeremy Begg

  +-+
  |VSM Software Services Pty. Ltd.  |
  | http://www.vsm.com.au/  |
  |-|
  | P.O.Box 402, Walkerville, |  E-Mail:  jer...@vsm.com.au |
  | South Australia 5081  |   Phone:  +61 8 8221 5188   |
  |---|  Mobile:  0414 422 947  |
  |  A.C.N. 068 409 156   | FAX:  +61 8 8221 7199   |
  +-+

___
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]

It's more or less a dead language, unless you are in a very specific 
environment. So no, most likely it is not worth learning, if you are 
thinking that you might work with it.


Compared to C? Well, it is similar, I'd guess/say.

  Johnny

On 2018-01-28 22:43, khandy21yo wrote:
There is a project on gitnub called BLISS-M. Is it comparable with any 
version of bliss discussed here?


Never had BLISS on anything until long after it would have been useful. 
So how does BLISS compare to C as a systems programming language? Is it 
worth learning at this late date?




Sent from my Galaxy Tab® A

 Original message 
From: Phil Budne 
Date: 1/28/18 1:59 PM (GMT-07:00)
To: simh@trailing-edge.com, p...@ultimate.com, fsword...@gmail.com
Subject: Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh 
for public access)


I wrote:
 > I found BLISS-11 sources and binaries in decus catalog item 10-325:
 > directory [43,50325] in (The DECUS catalog numbers are decimal

catalog number is 10-213 (decimal)
___
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



--
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)

[khandy21yo]

There is a project on gitnub called BLISS-M. Is it comparable with any version 
of bliss discussed here? 
Never had BLISS on anything until long after it would have been useful. So how 
does BLISS compare to C as a systems programming language? Is it worth learning 
at this late date?


Sent from my Galaxy Tab® A
 Original message From: Phil Budne  Date: 
1/28/18  1:59 PM  (GMT-07:00) To: simh@trailing-edge.com, p...@ultimate.com, 
fsword...@gmail.com Subject: Re: [Simh] 101 Basic Games for RSTS/E (was Re: 
PDP11 on Simh for public access) 
I wrote:
> I found BLISS-11 sources and binaries in decus catalog item 10-325:
> directory [43,50325] in (The DECUS catalog numbers are decimal

catalog number is 10-213 (decimal)
___
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))

[J. David Bryan]

On Sunday, January 28, 2018 at 15:42, Timothe Litt wrote:

> Was it admiral Nelson who observed that those who don't learn from
> history are doomed to repeat it?

George Santayana ("Those who cannot remember the past are condemned to 
repeat it").

  -- Dave

___
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]

I wrote:
> I found BLISS-11 sources and binaries in decus catalog item 10-325:
> directory [43,50325] in (The DECUS catalog numbers are decimal

catalog number is 10-213 (decimal)
___
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 27-Jan-18 13:59, Clem Cole wrote:
>
>
> On Fri, Jan 26, 2018 at 4:28 PM, Timothe Litt  > wrote:
>
> 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. 
>
> ​I was under the impression that the shared libraries were just that
> and DEC was pretty tight about if the fix was in the backend, all
> front end languages had to be tested (more in a minute).​
>
I could be wrong - I followed GEM development off and on as a matter of
curiosity, but didn't get into the internals - however, I was under the
impression that GEM was built into the compilers from object libraries,
not linked as sharable images.  In any case, GEM was not exposed or
documented externally.  And I don't recall any language-independent
patch being issued for GEM - common issues resulted in a patch for each
language - however things were packaged.

What was regression tested internally was quite different from what was
released.  BLISS was regression tested daily, but rarely released (even
internally).  IIRC, there were a lot of GEM changes to support C
optimization and FORTRAN parallelization.  (And language changes.)  And
those languages were released fairly frequently to satisfy customers &
benchmarks.  But I tracked progress through the GEM and language
notesfiles, so I may have a skewed view. 

> But I suspect there was marketing (and qualification) pull toward
> hiding the boundaries when packaging.
>
> ​Maybe in marketing (undeserved) but qual was in important.​
>
>  
>
> After all, some 3rd party might have written a backend for a
> non-DEC architecture.
>
> ​Unlikely -  the sad truth is that when both the K folks and Intel
> compiler groups had access to the all the code and the doc (and the
> people that designed it), guess what code base was used..  not GEM.​
>
That's reality - in a different space-time continuum. 

In the original (DEC-centric) STC, those decisions were made from the
point of view of DEC being the center of the universe, and not wanting
DEC's IP to leak onto other architectures.  Either BLISS itself, or
products coded in it.  The same view that didn't license XMI; greatly
restricted BI licenses; and was too little too late with expanding the
Alpha ecosystem.  (Contrast with PDP-11, where every Unibus system came
with a license grant to build a peripheral...)

Similarly, the DECision on BLISS pricing made sense if you looked at
what DEC invested (I think Brender's paper said a team of 16 people
(pre-GEM) and a couple of $M) and what having it was worth to DEC
engineering.  It didn't recognize how customers would value BLISS, or
what adoption by a wider crowd would be worth to DEC in the long run.

In the current STC, well, I saw a lot of NIH in Intel.  I suspect that
what you report amounts to "Why tear up a "perfectly good compiler" to
incorporate technology from a "failed company", when the result isn't
directly marketable?" 

Of course, both share the same defect - a shortsighted world view. 
Which is easy to see a few decades later.

> Grove used to say the DEC (Gem) compiler DNA was being ground up and
> reinserted into the Intel compiler.   To this day the Intel IL is not
> as rich as the Gem IL and it drives a lot of the old DEC team crazy.  
> From what I gather, the closest IL has been what LLVM did, but I
> gather than is still pretty weak for some language structures such as
> FORTRAN (and I believe PL/1).
>
I wouldn't know; it's been a long time since I dabbled in compilers. 
Mostly pre-GEM timeframe.  But I'm not surprised.  GEM was built &
evolved by engineers from the ground up to support multiple languages at
equivalent optimization levels.  Most other ILs start as an internal
tool for one language; when extended, the rule is to make minimal
changes to support each additional language.  This keeps short term
costs down (regressions against and changes to the first language - and
tools), but you lose expressiveness (and optimizations).  And it ends up
being warty and hackish.  But the incremental cost of the next wart/hack
is always less than the cost of rototilling.  There's probably a formal
proof to derive NIH from this observation :-)

Old New England axiom: Never time to do it right; always time to do it over.

Knuth's version: When writing software, do it once to understand the
problem.  Then plan on throwing out what you built, and write it
correctly from scratch.

Neither is put to use in the technology world...at least not often.

> Speaking for myself and my own personal experiences in using the both
> the DEC and Intel tool chains over the years, the common
> back-end/runtime is acute and you see how well Gem did vs an issue
> Intel has had.   I've spent years trying to get the testing
> and installer folks to 'get it'  when it comes to dependancies (I was
> once 

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

[Timothe Litt]

On 28-Jan-18 13:45, Tim Stark wrote:
> Folks,
>
> There is BLISS source codes for TOPS-20 in pdp-10.trailing-edge.com.
>
> There is a free copy of BLISS compilers for VAX and Alpha in Freeware CD 
> dist. 
>
> There is a online version of  The Design of an Optimizing Compiler on CMU 
> website.
>
> I have a question for you.  Does anyone know any documents to learn how to 
> write BLISS codes?
>
>
There is an internal course called BLISS Primer.  It may be on-line; if
not, when I get around to sending more stuff to CHM, I'm sure it will be.

In the TOPS-10 & -20 software notebooks, there are the BLISS-36 Language
Guide, Installation manual, User Guide

TOPS-10 also has the XPORT manual.  XPORT is a library for writing
portable code; including user-mode IO.  Don't know why it's not in the
TOPS-20 set (or maybe I missed it.)

The language guide is pretty readable, if you know another programming
language.

The paper that I referenced earlier gives some context and history.



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)

[Hunter Goatley]

On 1/28/2018 12:45 PM, Tim Stark wrote:


I have a question for you.  Does anyone know any documents to learn how to 
write BLISS codes?


It's also helpful to look at BLISS code. You can find all of the 
freeware programs in my VMS archive that are written in BLISS by going 
to this page and choosing BLISS for the Language.


http://vms.process.com/fileserv_search.html

--
Hunter
--
Hunter Goatley, Process Software,http://www.process.com/
goathun...@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)

[Hunter Goatley]

Hi, Tim.


I have a question for you.  Does anyone know any documents to learn how to 
write BLISS codes?


I'd recommend Matt Madison's "Introduction to BLISS" paper that he wrote 
back in 1993. Postscript and PDF files can be downloaded from here:


http://vms.process.com/ftp/vms-freeware/fileserv/bliss-intro.zip

You may also be interested in the original article by Wulf that 
introduced BLISS. You can find a PDF and Postscript files that I 
formatted here:


http://vms.process.com/ftp/vms-freeware/fileserv/bliss-intro.zip


--
Hunter
--
Hunter Goatley, Process Software,http://www.process.com/
goathun...@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)

[Tim Stark]

Folks,

There is BLISS source codes for TOPS-20 in pdp-10.trailing-edge.com.

There is a free copy of BLISS compilers for VAX and Alpha in Freeware CD dist. 

There is a online version of  The Design of an Optimizing Compiler on CMU 
website.

I have a question for you.  Does anyone know any documents to learn how to 
write BLISS codes?

Thanks,
Tim

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Phil Budne
Sent: Friday, January 26, 2018 12:09 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for 
public access)

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

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

Re: [Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Hunter Goatley]

On 1/28/2018 12:08 PM, Tim Stark wrote:


Folks,

I tried to configure DHCLIENT for DHCP access from my FIOS gateway 
router but DHCLIENT crashed during boot time and complaint undefined 
symbol in API libraries.


Also I am figuring out how to set SSH2 terminal server. I successfully 
generated SSH2 keys on emulated SIMH VAX system.


Does anyone know good DHCLIENT and SSH2 configuration instructions for 
OpenVMS 7.3 and Multinet 5.5?




SSH2 is covered in the /MultiNet Installation and Administration Guide/:

http://www.process.com/docs/multinet5_5/install_admin/chapter_28.htm

There's also an FAQ here:

http://www.process.com/support/multinet/faq/ssh.html

The DHCP client is documented here:

http://www.process.com/docs/multinet5_5/install_admin/chapter_16.htm

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

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

[Simh] VMS multinet DHCLIENT/SSH2 configuration problem

[Tim Stark]

Folks,

 

I tried to configure DHCLIENT for DHCP access from my FIOS gateway router
but DHCLIENT crashed during boot time and complaint undefined symbol in API
libraries. 

 

Also I am figuring out how to set SSH2 terminal server. I successfully
generated SSH2 keys on emulated SIMH VAX system.

 

Does anyone know good DHCLIENT and SSH2 configuration instructions for
OpenVMS 7.3 and Multinet 5.5?

 

I installed SIMH and OpenVMS 7.3 on my new Tinker SoC (Pi clone) with
Armbian OS for 7/24 operation. 

 

Tim

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