I agree. It's an interesting topic!
------Origineel bericht------
Van: sampsa at mac.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] SCSISE adapter -> listings
Verzonden: 14 januari 2013 23:28
I would suggest moving this conversation (which I personally find very interesting) to the DECtec mailing list, which can be found at http://dectec.info
sampsa
On 15 Jan 2013, at 00:25, Clem Cole <clemc at ccc.com> wrote:
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
I would suggest moving this conversation (which I personally find very interesting) to the DECtec mailing list, which can be found at http://dectec.info
sampsa
On 15 Jan 2013, at 00:25, Clem Cole <clemc at ccc.com> wrote:
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
On Mon, Jan 14, 2013 at 5:08 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
DEC C I/O is just a wrapper around RMS
Please take this off list if you want to continue to discuss it.
Clem Cole <clemc at ccc.com> writes:
On Mon, Jan 14, 2013 at 4:02 PM, Brian Schenkenberger, VAXman- <
system at tmesis.com> wrote:
BLISS has no I/O, and if you want to be pedantic, nor does C. I/O is
all via support libraries which provide I/O. Neither language has any
inherent I/O syntax. A BLISS coder would call some VMS RTL or delve >
into $QIO to do I/O. >
Absolutely correct. Sorry to confuse >>in practice<< it was two
different models, but you are right, the languages did not force an I/O
model in the language semantics. So the the issue degenerates to VMS
RMS (record I/O - from the IBM mainframe) vs stream I/O - the C/Multics
(byte stream) style.
When VAX was first envisioned GB et al, wanted a machine to go after the
360/370 family. An efficient RMS was considered a requirement and the
crew did an amazing job. It was small, fast and worked extremely well.
I t was complicated but lots of people and it sounds like you are/were
in that camp, loved it.
But after VAX-11C was released and stream I/O installed, engineering
discovered that stream I/O was preferred by more people, and in
particular us OS types discovered we preferred it. FYI: Dave added
stream I/O to VMS for VAX-11/C (urban legend is in an weekend - but I
really do not think that was true - I was not on the VMS team, although
a number of my friends were).
My memory is hazy here, but I think there was a point where the compiler
team rewrote the FTN runtime support from RMS into stream code soon
their after and "their was much rejoicing." They are likely to have
done it in BLISS, but again, I'd have to ask one the old compiler guys
that actually did the work and few are left.
As I said in a previous message I still see Grove socially every so
often, but since he retired a few years ago; he's not as accessible. If
you have a specific question, that I do not know the answer, I >>might<<
be able to find some one that can. But I'd prefer this off-list, please
send it to me directly, with a working return email address.
WRT VAX C, I'd have to pull out an old V5.n release and install it to be
certain but DEC C I/O is just a wrapper around RMS, et al. It HAS to be
or RMS CDC simply would not function... and it most certainly does!
WRT the Fortran RTL rewrite: I haven't looked; however, the COBOL RTL has
certainly been rewritten in recent times in C. It caused me many too many
a headache trying to deal with Pthreads in the midsts of RMS's own unique
threading to implement CDC. There weren't real Pthread threads but due to
resourcing the COBOL RTL in C, the excess baggage of the TEB came along in
every I/O.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Mon, Jan 14, 2013 at 4:02 PM, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
BLISS has no I/O, and if you want to be pedantic, nor does C. I/O is
all via support libraries which provide I/O. Neither language has any
inherent I/O syntax. A BLISS coder would call some VMS RTL or delve
into $QIO to do I/O.
Absolutely correct. Sorry to confuse >>in practice<< it was two different models, but you are right, the languages did not force an I/O model in the language semantics. So the the issue degenerates to VMS RMS (record I/O - from the IBM mainframe) vs stream I/O - the C/Multics (byte stream) style.
When VAX was first envisioned GB et al, wanted a machine to go after the 360/370 family. An efficient RMS was considered a requirement and the crew did an amazing job. It was small, fast and worked extremely well. I t was complicated but lots of people and it sounds like you are/were in that camp, loved it.
But after VAX-11C was released and stream I/O installed, engineering discovered that stream I/O was preferred by more people, and in particular us OS types discovered we preferred it. FYI: Dave added stream I/O to VMS for VAX-11/C (urban legend is in an weekend - but I really do not think that was true - I was not on the VMS team, although a number of my friends were).
My memory is hazy here, but I think there was a point where the compiler team rewrote the FTN runtime support from RMS into stream code soon their after and "their was much rejoicing." They are likely to have done it in BLISS, but again, I'd have to ask one the old compiler guys that actually did the work and few are left.
As I said in a previous message I still see Grove socially every so often, but since he retired a few years ago; he's not as accessible. If you have a specific question, that I do not know the answer, I >>might<< be able to find some one that can. But I'd prefer this off-list, please send it to me directly, with a working return email address.
Clem
On 14 Jan 2013, at 16:07, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Cory Smelosky <b4 at gewt.net> writes:
No matter the version top/htop always shows 100% CPU. What distro are =
you using?
Ubuntu is on my laptops.
I must have misconfigured something hmmmmm.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
Cory Smelosky <b4 at gewt.net> writes:
No matter the version top/htop always shows 100% CPU. What distro are =
you using?
Ubuntu is on my laptops.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 14 Jan 2013, at 15:08, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM> wrote:
Cory Smelosky <b4 at gewt.net>
On 14 Jan 2013, at 14:34, "Brian Schenkenberger, VAXman-" <system at TMESIS.COM=
wrote:
Brian Hechinger <wonko at 4amlunch.net> writes:=20
=20
What's the best alpha emulator to go with?
=20
AlphaVM-free from Emu/VM. Runs under Linux. Artem recently made updates
to it at my request to allow use of the Linux bridge and tunnel devices
to make a self-contained Xwindows accessible instance running on Linux.
It's now like having a portable Alpha! I've also successfully clustered
my 17" HP ENvy running AlphaVM-free. Had to use wired-ehternet. Bridge
and tunnel would not play nicely with the wireless ethernet
Now if only it didnt appear to constantly use 100% CPU. ;)
AlphaVM-free appears to use less than 20% on my Envy. Are you running the
latest build 1.2.2??? Try 1.1.11. That's what I've been running and it's
not consuming much CPU at all.
No matter the version top/htop always shows 100% CPU. What distro are you using?
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
Clem Cole <clemc at ccc.com> writes:
--e89a8ff2534a88b73804d345c72d Content-Type: text/plain;
charset=ISO-8859-1
On Mon, Jan 14, 2013 at 10:13 AM, Brian Schenkenberger, VAXman- <
system at tmesis.com> wrote:
It was a question of why go out of ones > way to recode in C. >
No idea, but the numbers did not lie. The customers wanted C not BLISS
and if you look at the number of customer projects that switched to it
outside<< of DEC, it was not even close.
I learned BLISS/10 and BLISS/11 (and eventually BLISS/32) at CMU on the
10s before I learned C. When I first saw C (the white book had not yet
been written) and I was not not assumed, particularly since the BLISS
macro processor and code generator were so far advanced from dmr's
compiler. But I quickly learned that I >>preferred<< C for a number of
reasons. Originally, because it was self-hosting which BLISS was not
for the PDP-11 and my edit/compile/test cycle was just so much easier.
That said for early VMS editions, when there was not C, all we had was
BLISS, so I used it; but I also used to grumble as I had been
enlightened from the dark side. I can definitely state that Stan and I
had had Culter's VAX11-C when wrote the TCP stack we would have use it
not BLISS - but it was all we had and his compiler was a good 3-4 years
into the future.
Late on Larry and I used to talk about this at lunch. I think most of
the system folks in the VMS group that really learned C, eventually came
to the same spot as I did. It was just an easier echo system to use;
but they key was that were not trying to use BLISS I/O, we used C calls
once we switch over - which may have been what make you think that it's
support was not as good.
BLISS has no I/O, and if you want to be pedantic, nor does C. I/O is
all via support libraries which provide I/O. Neither language has any
inherent I/O syntax. A BLISS coder would call some VMS RTL or delve
into $QIO to do I/O.
I don't understand your comment: what make you think that it's support
was not as good. The CRTL functions are wrappers calling RMS, RTL or
system services. Their "support" is as good as the implementation of
the underlying services they evoke.
That said, the compiler guys (Grove at al), doggedly stayed with BLISS
to the end. Rich and I have also talked about the issue, including the
"what if GEM has been in C not BLISS" - would Intel have been able to
accept it as the base? An interesting thought [instead the DEC DNA is
ground up and reinjected].
There are a lot of other details/issues. I'll ask Mr. Compiler if he'd
care to comment WRT to this. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
