OpenVMS.Org are looking to collect and confirm some information about OpenVMS users and usage. Please take a few minutes to complete this 13 question poll. Your input is valuable. 
http://www.openvms.org/pages.php?page=Quick-Poll

On Thursday, August 16, 2012 8:37:45 AM UTC-5, Ian Miller wrote:
> OpenVMS.Org are looking to collect and confirm some information about OpenVMS users and usage. Please take a few minutes to complete this 13 question poll. Your input is valuable. http://www.openvms.org/pages.php?page=Quick-Poll

I'll wander over to openvms.org and decide about the survey, but I must mention that this is the slowest (by far) web site I visit.  YMMV

On Aug 16, 2:37=A0pm, Ian Miller <g...@uk2.net> wrote:
> OpenVMS.Org are looking to collect and confirm some information about Ope=
nVMS users and usage. Please take a few minutes to complete this 13 questio=
n poll. Your input is valuable.http://www.openvms.org/pages.php?page=3DQuic=
k-Poll

"would you use OpenVMS I64 running on x86 using an Integrity Virtual
Machine in a production environment"

?

If that is intended to read as it is written, then it might be helpful
to expand on the concept a bit (a linked page? or is the Wikipedia
article sufficient?), for the benefit of those VMS folk who until now
have had no interest in what's been available on IA64.

On 2012-08-16 19:21:30 +0000, John Wallace said:

> On Aug 16, 2:37�pm, Ian Miller <g...@uk2.net> wrote:
>> OpenVMS.Org are looking to collect and confirm some information about 
>> OpenVMS users and usage. Please take a few minutes to complete this 13 
>> question poll. Your input is 
>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
> 
> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
> Machine in a production environment"
> 
> ?
> 
> If that is intended to read as it is written, then it might be helpful
> to expand on the concept a bit (a linked page? or is the Wikipedia
> article sufficient?), for the benefit of those VMS folk who until now
> have had no interest in what's been available on IA64.

As written, that question is quite confusing.  Or the questioner is 
confused.  The HP Integrity Virtual Machine product is an Itanium-only 
product, and restricted to specific recent Itanium processors in 
Integrity servers, and restricted to hosting non-nested guest operating 
systems (including OpenVMS) atop the HP-UX host operating system.   You 
can't stack an HP VM atop an HP VM, unlike what is possible with IBM 
VM.  That question could then mean a mix of x86 and Itanium processors 
in the same box, such as is possible with the existing c-class 
BladeSystem configurations.  Or that there's consideration being given 
here around an x86-64 port of an Itanium emulator, and this question 
would be an odd way to pursue/announce/consider that engineering work.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 8/16/2012 1:21 PM, John Wallace wrote:
> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>> OpenVMS.Org are looking to collect and confirm some information about OpenVMS users and usage. Please take a few minutes to complete this 13 question poll. Your input is valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>
> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
> Machine in a production environment"
>
> ?
>
> If that is intended to read as it is written, then it might be helpful
> to expand on the concept a bit (a linked page? or is the Wikipedia
> article sufficient?), for the benefit of those VMS folk who until now
> have had no interest in what's been available on IA64.

A number of folks today run OpenVMS VAX under a VAX emulator or OpenVMS 
Alpha under an Alpha emulator, running on top of an x86 platform.

I read this question as: Would you be willing to run the Itanium version 
of OpenVMS under an Itanium emulator (using a hypothetical example of HP 
VM ported to x86) on top of an x86 platform, and do so for your 
Production work?

On 2012-08-17 15:05:46 +0000, Keith Parris said:

> On 8/16/2012 1:21 PM, John Wallace wrote:
>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>> OpenVMS.Org are looking to collect and confirm some information about 
>>> OpenVMS users and usage. Please take a few minutes to complete this 13 
>>> question poll. Your input is 
>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>> 
>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>> Machine in a production environment"
>> 
>> ?
>> 
>> If that is intended to read as it is written, then it might be helpful
>> to expand on the concept a bit (a linked page? or is the Wikipedia
>> article sufficient?), for the benefit of those VMS folk who until now
>> have had no interest in what's been available on IA64.
> 
> A number of folks today run OpenVMS VAX under a VAX emulator or OpenVMS 
> Alpha under an Alpha emulator, running on top of an x86 platform.
> 
> I read this question as: Would you be willing to run the Itanium 
> version of OpenVMS under an Itanium emulator (using a hypothetical 
> example of HP VM ported to x86) on top of an x86 platform, and do so 
> for your Production work?


HP can either fix the wording of that question, or HP will receive 
feedback on whatever the end-user thought that acronym soup meant (to 
them), and HP can then apply that data to whatever the HP author(s) 
intended with that question.    What could possibly go wrong?

Keith - from your interpretation - I can't tell if the folks at HP that 
crafted that question understand the difference between an "emulator" 
or "simulator" (e.g. simh) and a "virtual machine" (e.g. HP IVM), or if 
they're mixing that distinction together into a porridge of confusion 
and disappointment.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 8/16/2012 1:49 PM, Stephen Hoffman wrote:
> On 2012-08-16 19:21:30 +0000, John Wallace said:
>
>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>> OpenVMS.Org are looking to collect and confirm some information about
>>> OpenVMS users and usage. Please take a few minutes to complete this
>>> 13 question poll. Your input is
>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>
>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>> Machine in a production environment"
>>
>> ?
>>
>> If that is intended to read as it is written, then it might be helpful
>> to expand on the concept a bit (a linked page? or is the Wikipedia
>> article sufficient?), for the benefit of those VMS folk who until now
>> have had no interest in what's been available on IA64.
>
> As written, that question is quite confusing.  Or the questioner is
> confused.

Or perhaps it's more a matter of trying to describe something that 
doesn't yet exist in terms of familiar things that do exist.

> The HP Integrity Virtual Machine product is an Itanium-only
> product, and restricted to specific recent Itanium processors in
> Integrity servers, and restricted to hosting non-nested guest operating
> systems (including OpenVMS) atop the HP-UX host operating system.   You
> can't stack an HP VM atop an HP VM, unlike what is possible with IBM
> VM.

That describes the situation today.

 > That question could then mean a mix of x86 and Itanium processors
> in the same box, such as is possible with the existing c-class
> BladeSystem configurations.

No, because it says "OpenVMS I64 running on x86 ..."

> Or that there's consideration being given
> here around an x86-64 port of an Itanium emulator, and this question
> would be an odd way to pursue/announce/consider that engineering work.

I suspect this is the most likely option.

I'm not privy to any plans, but thinking in terms of what's technically 
possible: Consider what you would have it you took the Ski Itanium CPU 
emulator (which lacks emulation of any platform hardware) and added 
enough code from HP VM to provide a platform environment which looks 
just like HP VM to the VMS instance inside (with the HP VM code adjusted 
for endian-ness, and to run on Linux instead of HP-UX). No changes would 
be required in OpenVMS I64 code for it to run inside such an environment.

On 8/17/2012 9:26 AM, Stephen Hoffman wrote:
> I can't tell if the folks at HP that
> crafted that question understand the difference between an "emulator" or
> "simulator" (e.g. simh) and a "virtual machine" (e.g. HP IVM)

I've noticed that multiple VAX/Alpha emulator software vendors refer to 
their products using the terms Hardware Virtualization and/or Virtual 
Machine.

On 2012-08-17 15:31:11 +0000, Keith Parris said:

> On 8/16/2012 1:49 PM, Stephen Hoffman wrote:
> 
>> Or that there's consideration being given
>> here around an x86-64 port of an Itanium emulator, and this question
>> would be an odd way to pursue/announce/consider that engineering work.
> 
> I suspect this is the most likely option.
> 
> I'm not privy to any plans, but thinking in terms of what's technically 
> possible: Consider what you would have it you took the Ski Itanium CPU 
> emulator (which lacks emulation of any platform hardware) and added 
> enough code from HP VM to provide a platform environment which looks 
> just like HP VM to the VMS instance inside (with the HP VM code 
> adjusted for endian-ness, and to run on Linux instead of HP-UX). No 
> changes would be required in OpenVMS I64 code for it to run inside such 
> an environment.

While it would not surprise me that there were third-party providers 
looking to provide Itanium emulation (and leaving aside all discussions 
of the long-term value of that approach for OpenVMS end-users), I'd 
(still) be skeptical around the value of any data returned from that 
survey question, due to its (confusing) wording.




-- 
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote 2012-08-17 17:26:
> On 2012-08-17 15:05:46 +0000, Keith Parris said:
>
>> On 8/16/2012 1:21 PM, John Wallace wrote:
>>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>>> OpenVMS.Org are looking to collect and confirm some information about
>>>> OpenVMS users and usage. Please take a few minutes to complete this 13
>>>> question poll. Your input is
>>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>>
>>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>>> Machine in a production environment"
>>>
>>> ?
>>>
>>> If that is intended to read as it is written, then it might be helpful
>>> to expand on the concept a bit (a linked page? or is the Wikipedia
>>> article sufficient?), for the benefit of those VMS folk who until now
>>> have had no interest in what's been available on IA64.
>>
>> A number of folks today run OpenVMS VAX under a VAX emulator or OpenVMS
>> Alpha under an Alpha emulator, running on top of an x86 platform.
>>
>> I read this question as: Would you be willing to run the Itanium version
>> of OpenVMS under an Itanium emulator (using a hypothetical example of HP
>> VM ported to x86) on top of an x86 platform, and do so for your
>> Production work?
>
>
> HP can either fix the wording of that question...........

OK, I might have missunderstod things here, but...

Does openvms.org equal "HP" ?
*Who* is actualy asking here ?

Jan-Erik.

On 8/17/2012 10:31 AM, Keith Parris wrote:
>
> I'm not privy to any plans, but thinking in terms of what's technically
> possible: Consider what you would have it you took the Ski Itanium CPU
> emulator (which lacks emulation of any platform hardware) and added
> enough code from HP VM to provide a platform environment which looks
> just like HP VM to the VMS instance inside (with the HP VM code adjusted
> for endian-ness, and to run on Linux instead of HP-UX). No changes would
> be required in OpenVMS I64 code for it to run inside such an environment.

The Ski emulator would only be needed if the HP VM was not running on 
Itanium.  And the HP VM would not still not provide what was needed. 
The SKI emulator would have to be further enhanced.  Based on the 
description on the project page, the SKI emulator appears to be only 
emulating the user mode instructions, not the stuff needed for the VMS 
kernel to run.  That would be way too much work.

There is a simpler (relatively) way:

The first step for this hack would be to get the SKI Emulator running on 
Alpha/VMS so that you could have it load up and run an IA64 VMS ELF 
image, and configure it to call VMS/ALPHA library routines and system 
services instead of trying to make Linux routine calls as it does now 
according to the documentation.

Once you got that working, you could then hack the VMS image activator 
to launch that emulator when you tried to run that type of an image 
instead of running your own launcher.

While at this point, you might think it was a waste of time to do this 
because you end up with something slower than the original, read on.

After all, what is available for VMS on Itanium that is not also 
available for VMS on Alpha?

You then either do what is needed to stabilize an open source Alpha 
Emulator like the ES40 so that it can run VMS reliably if that is needed 
for it, or partner with one or more of the commercial Alpha emulators, 
because you need a way to break out of emulation and call native code.

There you make the change so that the an emulated Alpha program can call 
routines compiled in the native x86-64 instruction set.  This is 
something like a CMX86 trap.  The emulator would then run the user-mode 
code as native.  You would need to have a way for the x86-64 code to 
call VMS/Alpha library routines and system services, just like above.

But now you have binaries running at the native x86-64 speed except when 
making library calls.

Now the literature for some of the advanced emulators are caching some 
translated Alpha/VAX code with native code to get the speed up, so 
commonly used sections of VMS would be effectively running in x86 mode.

Now if you still need Itanium compatibility, you compile the previously 
ported SKI emulator to be native x86.  Now you have a x86 VMS emulator 
that can run Alpha, IA64, and native X86-64 all at the same time.

It is possible that the emulator vendors could each come up with their 
own method of running user built x86-64 code, but that would require 
software vendors that wanted that speed boost to compile on all the 
different emulator platforms.  From the ISV point of view, it would be 
better if someone worked out a common interface and building 
instructions for this.

If you do not need to support Itanium/VMS binaries, then you can skip 
that part and still have Alpha/VMS + x86-64/VMS binaries running on the 
same hardware.

And HP could use this to gradually supply parts of Alpha/VMS that also 
came with precompiled x86-64 binaries.

This gives you both backward binary compatibility and the ability to 
take advantage of newer x86-64 processors.

Another component that is needed for the emulators is paravirtualized 
drivers.  These would be custom device drivers that would use that 
"CMX86" trap to turn the actual I/O processing to the emulator host 
instead of having to have the emulator spend cycles emulating the actual 
I/O hardware.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

Comparing EPIC to Risc,

would an X86 based platform emulator be able to better optimise RISC
machine code (from say Alpha) compared to EPIC machine code (from say
Itanium) ?

or would Itanium machine code have and edge because  the explicit
instructions for parralel processing would allow the emulator to
translate and process the explicit chunks of code in parralel ?

Would an Alpha emulator incorporate much of the alpha smarts in it ?
(such as predictive branching and pre-translating both possible outcomes
of a branch ?)

Or do they end up being more akin to compilers, translating a big chunk
of foreign machine code into native code and branching to it, allowing
the X86 CPU to do any optimisations it can while running native code ?


Since IBM has the rights to the translator that Apple used as "Rosetta",
I wonder if it might be able to provide better support for VMS (Alpha
and/or Itanium) on its AIX/Power platform.

This could give IBM a boost by stealing the BCS customer base and giving
them better emulation and performance than what HP could.

Subject: Re: OpenVMS.Org quick pool
                               ^^^^

Would that be the non-paged pool?

On Aug 17, 4:31=A0pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:
> On 8/16/2012 1:49 PM, Stephen Hoffman wrote:
>
>
>
>
>
>
>
>
>
> > On 2012-08-16 19:21:30 +0000, John Wallace said:
>
> >> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
> >>> OpenVMS.Org are looking to collect and confirm some information about
> >>> OpenVMS users and usage. Please take a few minutes to complete this
> >>> 13 question poll. Your input is
> >>> valuable.http://www.openvms.org/pages.php?page=3DQuick-Poll
>
> >> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
> >> Machine in a production environment"
>
> >> ?
>
> >> If that is intended to read as it is written, then it might be helpful
> >> to expand on the concept a bit (a linked page? or is the Wikipedia
> >> article sufficient?), for the benefit of those VMS folk who until now
> >> have had no interest in what's been available on IA64.
>
> > As written, that question is quite confusing. =A0Or the questioner is
> > confused.
>
> Or perhaps it's more a matter of trying to describe something that
> doesn't yet exist in terms of familiar things that do exist.
>
> > The HP Integrity Virtual Machine product is an Itanium-only
> > product, and restricted to specific recent Itanium processors in
> > Integrity servers, and restricted to hosting non-nested guest operating
> > systems (including OpenVMS) atop the HP-UX host operating system. =A0 Y=
ou
> > can't stack an HP VM atop an HP VM, unlike what is possible with IBM
> > VM.
>
> That describes the situation today.
>
> =A0> That question could then mean a mix of x86 and Itanium processors
>
> > in the same box, such as is possible with the existing c-class
> > BladeSystem configurations.
>
> No, because it says "OpenVMS I64 running on x86 ..."
>
> > Or that there's consideration being given
> > here around an x86-64 port of an Itanium emulator, and this question
> > would be an odd way to pursue/announce/consider that engineering work.
>
> I suspect this is the most likely option.
>
> I'm not privy to any plans, but thinking in terms of what's technically
> possible: Consider what you would have it you took the Ski Itanium CPU
> emulator (which lacks emulation of any platform hardware) and added
> enough code from HP VM to provide a platform environment which looks
> just like HP VM to the VMS instance inside (with the HP VM code adjusted
> for endian-ness, and to run on Linux instead of HP-UX). No changes would
> be required in OpenVMS I64 code for it to run inside such an environment.

In terms of "what's technically possible", I'd have thought cutting
Itanium out of the loop completely and porting VMS to AMD64 would be
an interesting option for some of the remaining customers, maybe even
for some organisations who are not currently customers. Using an
emulation layer to provide an IA64-like environment on an AMD64 box
would require constructing an IA64 *system* emulator, not just chip
emulator, on AMD64. More overhead, more points of failure.

The "VMS native on AMD64" option may not be commercially attractive to
today's HP/Intel, for various reasons (possibly even including HP
wanting the option to say "your emulated VMS on emulated IA64 too slow/
too unreliable? Buy my real IA64 instead, special offers while stocks
last").

I don't really care all that much whether we call it an emulator, a
simulator, virtualization, or a banana boat, as long as it's clear
what we're talking about. Is it clear right now? No.

Nor does the poll seem to address the question of folks who aren't
currently using VMS but might use VMS if the involvement of IA64 (in
some form) wasn't mandatory.

oh well, it's a start.

JF Mezei wrote:
> Comparing EPIC to Risc,
> 
> would an X86 based platform emulator be able to better optimise RISC
> machine code (from say Alpha) compared to EPIC machine code (from say
> Itanium) ?
> 
> or would Itanium machine code have and edge because  the explicit
> instructions for parralel processing would allow the emulator to
> translate and process the explicit chunks of code in parralel ?
> 
> Would an Alpha emulator incorporate much of the alpha smarts in it ?
> (such as predictive branching and pre-translating both possible outcomes
> of a branch ?)
> 
> Or do they end up being more akin to compilers, translating a big chunk
> of foreign machine code into native code and branching to it, allowing
> the X86 CPU to do any optimisations it can while running native code ?
> 
> 
> Since IBM has the rights to the translator that Apple used as "Rosetta",
> I wonder if it might be able to provide better support for VMS (Alpha
> and/or Itanium) on its AIX/Power platform.
> 
> This could give IBM a boost by stealing the BCS customer base and giving
> them better emulation and performance than what HP could.
> 

Still trying to stick the knife between the "H" and the "P", huh ??

:-)

Keith Parris wrote:
> On 8/16/2012 1:21 PM, John Wallace wrote:
>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>> OpenVMS.Org are looking to collect and confirm some information about 
>>> OpenVMS users and usage. Please take a few minutes to complete this 
>>> 13 question poll. Your input is 
>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>
>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>> Machine in a production environment"
>>
>> ?
>>
>> If that is intended to read as it is written, then it might be helpful
>> to expand on the concept a bit (a linked page? or is the Wikipedia
>> article sufficient?), for the benefit of those VMS folk who until now
>> have had no interest in what's been available on IA64.
> 
> A number of folks today run OpenVMS VAX under a VAX emulator or OpenVMS 
> Alpha under an Alpha emulator, running on top of an x86 platform.
> 
> I read this question as: Would you be willing to run the Itanium version 
> of OpenVMS under an Itanium emulator (using a hypothetical example of HP 
> VM ported to x86) on top of an x86 platform, and do so for your 
> Production work?
> 

That then would raise the question, which hardware is "easiest", "fastest", 
"best" to emulate ?

I'd be highly surprised if there is any software running on VMS on IA-64 for 
which there is no sources.  The painful lessons were first learned going from 
VAX to Alpha.  If there is, well, the "hindmost" is usually the first to get caught.

Other than speed, how many users really needed Alpha?  Ok, availability too.  I 
wonder what percentage of those still using VMS actually need the capabilities 
of Alpha.  There is also those things implemented on Alpha, but never 
implemented on VAX.  Even so, that is software, not hardware.

A good question is, "is an emulated Alpha surperior to an emulated VAX?", all 
else being equal?  I'd be interested to know.

I'd also be interested to know if any emulators have performance similar to or 
greater than my AS800 and DS20?  Wonder if such information is available?

Stephen Hoffman wrote:
> On 2012-08-17 15:05:46 +0000, Keith Parris said:
> 
>> On 8/16/2012 1:21 PM, John Wallace wrote:
>>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>>> OpenVMS.Org are looking to collect and confirm some information 
>>>> about OpenVMS users and usage. Please take a few minutes to complete 
>>>> this 13 question poll. Your input is 
>>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>>
>>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>>> Machine in a production environment"
>>>
>>> ?
>>>
>>> If that is intended to read as it is written, then it might be helpful
>>> to expand on the concept a bit (a linked page? or is the Wikipedia
>>> article sufficient?), for the benefit of those VMS folk who until now
>>> have had no interest in what's been available on IA64.
>>
>> A number of folks today run OpenVMS VAX under a VAX emulator or 
>> OpenVMS Alpha under an Alpha emulator, running on top of an x86 platform.
>>
>> I read this question as: Would you be willing to run the Itanium 
>> version of OpenVMS under an Itanium emulator (using a hypothetical 
>> example of HP VM ported to x86) on top of an x86 platform, and do so 
>> for your Production work?
> 
> 
> HP can either fix the wording of that question, or HP will receive 
> feedback on whatever the end-user thought that acronym soup meant (to 
> them), and HP can then apply that data to whatever the HP author(s) 
> intended with that question.    What could possibly go wrong?
> 
> Keith - from your interpretation - I can't tell if the folks at HP that 
> crafted that question understand the difference between an "emulator" or 
> "simulator" (e.g. simh) and a "virtual machine" (e.g. HP IVM), or if 
> they're mixing that distinction together into a porridge of confusion 
> and disappointment.
> 
> 
> 

Was the questioner developed by HP?  I didn't see any claims to this.  All I saw 
was OpenVMS.org.

David Froble wrote 2012-08-18 22:22:
> Keith Parris wrote:
>> On 8/16/2012 1:21 PM, John Wallace wrote:
>>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>>> OpenVMS.Org are looking to collect and confirm some information about
>>>> OpenVMS users and usage. Please take a few minutes to complete this 13
>>>> question poll. Your input is
>>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>>
>>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>>> Machine in a production environment"
>>>
>>> ?
>>>
>>> If that is intended to read as it is written, then it might be helpful
>>> to expand on the concept a bit (a linked page? or is the Wikipedia
>>> article sufficient?), for the benefit of those VMS folk who until now
>>> have had no interest in what's been available on IA64.
>>
>> A number of folks today run OpenVMS VAX under a VAX emulator or OpenVMS
>> Alpha under an Alpha emulator, running on top of an x86 platform.
>>
>> I read this question as: Would you be willing to run the Itanium version
>> of OpenVMS under an Itanium emulator (using a hypothetical example of HP
>> VM ported to x86) on top of an x86 platform, and do so for your
>> Production work?
>>
>
> That then would raise the question, which hardware is "easiest", "fastest",
> "best" to emulate ?
>
> I'd be highly surprised if there is any software running on VMS on IA-64
> for which there is no sources.  The painful lessons were first learned
> going from VAX to Alpha.  If there is, well, the "hindmost" is usually the
> first to get caught.
>
> Other than speed, how many users really needed Alpha?  Ok, availability
> too.  I wonder what percentage of those still using VMS actually need the
> capabilities of Alpha.

That is, still using VMS *today* that needed Alpha *then* ?
Or that could run their VMS operations on VAX *today* ??

I guess most "still using VMS" today are larger operations.

And didn't most of us saw the benefits? Faster and larger memories.
Noone needed larger memory than VAX supported? Well, maybe not from
day one of Alpha, but a bit later and in particular *today*?


> There is also those things implemented on Alpha,
> but never implemented on VAX.  Even so, that is software, not hardware.
>
> A good question is, "is an emulated Alpha surperior to an emulated VAX?",
> all else being equal?  I'd be interested to know.

Yes, since Alpha's run later versions of VMS (and Rdb) then VAX does.
That's enough for me.

Jan-Erik.

Jan-Erik Soderholm wrote:
> David Froble wrote 2012-08-18 22:22:

>> That then would raise the question, which hardware is "easiest", 
>> "fastest",
>> "best" to emulate ?

Note that the question is just about emulation of hardware.  Not talking about 
software.

>> I'd be highly surprised if there is any software running on VMS on IA-64
>> for which there is no sources.  The painful lessons were first learned
>> going from VAX to Alpha.  If there is, well, the "hindmost" is usually 
>> the
>> first to get caught.
>>
>> Other than speed, how many users really needed Alpha?  Ok, availability
>> too.  I wonder what percentage of those still using VMS actually need the
>> capabilities of Alpha.
> 
> That is, still using VMS *today* that needed Alpha *then* ?
> Or that could run their VMS operations on VAX *today* ??
> 
> I guess most "still using VMS" today are larger operations.
> 
> And didn't most of us saw the benefits? Faster and larger memories.
> Noone needed larger memory than VAX supported? Well, maybe not from
> day one of Alpha, but a bit later and in particular *today*?

This gets away from the question.  If any emulation is running on an x86, where 
CPU and memory and all else is the same, then the question that I posed is which 
HW could be "easiest, best, fastest" emulated.

>> There is also those things implemented on Alpha,
>> but never implemented on VAX.  Even so, that is software, not hardware.
>>
>> A good question is, "is an emulated Alpha surperior to an emulated VAX?",
>> all else being equal?  I'd be interested to know.
> 
> Yes, since Alpha's run later versions of VMS (and Rdb) then VAX does.
> That's enough for me.

Again, that's software, not hardware.

As an exercise, suppose that your options are emulated VAX, and emulated Alpha, 
and the emulated VAX gave better performance than the emulated ALpha.  Without 
getting into software versions, which would you prefer.

That would of course raise the question of how hard would it be to get VMS V8.4 
running on VAX, which I doubt would be feasible because of the 64 bit stuff.

But the question I was asking was, which HW would perform best in emulation on 
x86?  I think it is an interesting question.

> Jan-Erik.
> 

On Sat, 18 Aug 2012 23:19:06 -0400, David Froble wrote:

> Jan-Erik Soderholm wrote:
>> 
>> Yes, since Alpha's run later versions of VMS (and Rdb) then VAX does.
>> That's enough for me.
> 
> Again, that's software, not hardware.
> 
> As an exercise, suppose that your options are emulated VAX, and emulated
> Alpha, and the emulated VAX gave better performance than the emulated
> ALpha.  Without getting into software versions, which would you prefer.

For VAX:

a) a longer history of emulators, and corresponding maturity of those 
products?

b) better hardware error reporting tools?  With the succession of Alpha 
diagnostics from DECevent to WEBES, to <I lost track somewhere>, doesn't 
VAX/VMS 7.3 represent stability here?

> That would of course raise the question of how hard would it be to get
> VMS V8.4 running on VAX, which I doubt would be feasible because of the
> 64 bit stuff.
> 
> But the question I was asking was, which HW would perform best in
> emulation on x86?  I think it is an interesting question.

I think this is where you cannot avoid the question of software and 
availability of long term support for VAX/VMS.

-- 
Paul Sture

On 8/17/2012 8:04 PM, John E. Malmberg wrote:
> The
> SKI emulator would have to be further enhanced.  Based on the
> description on the project page, the SKI emulator appears to be only
> emulating the user mode instructions, not the stuff needed for the VMS
> kernel to run.

 From http://ski.sourceforge.net/, first paragraph:
"ski supports the full instruction set of the architecture, including 
privileged instructions and associated semantics."

> Now you have a x86 VMS emulator
> that can run Alpha, IA64, and native X86-64 all at the same time.

Given that Simh VAX emulation code is well-proven and readily available 
in open source form, you could use the same approach to execute VAX 
executable images as well.

In article <k0lo3u$guc$1@usenet01.boi.hp.com>, Keith Parris <keithparris_deletethis@yahoo.com> writes:

> No changes would 
> be required in OpenVMS I64 code for it to run inside such an environment.

   And no performance would be achieved.  x86 isn't yet fast enough and
   IA64 isn't slow enough for x86 to emulate IA64 at near IA64 hardware
   speeds.

   Like emulating VAXen on modern chips, it could get there, some day.
   But if someone had decided to keep making VAXen, I suspect they'd
   be using modern processes and clock speeds, and VAX emulators wouldn't
   be running on chips with so much advantage that the emulation beats
   hardware speed.

   In the intervening years, Alpha was one hot chip, and IA64 wasn't
   bad.  Where would IA64 customers go in the meantime for VMS at
   competitive performance?

In article <502f2ec1$0$44958$c3e8da3$33881b6a@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Comparing EPIC to Risc,
> 
> would an X86 based platform emulator be able to better optimise RISC
> machine code (from say Alpha) compared to EPIC machine code (from say
> Itanium) ?

   VEST Phase IV vs. VEST Phase V?

   (Names I just made up.)

 JF Mezei wrote:
> 
> Would an Alpha emulator incorporate much of the alpha smarts in it ?
> (such as predictive branching and pre-translating both possible outcomes
> of a branch ?)
> 
> Or do they end up being more akin to compilers, translating a big chunk
> of foreign machine code into native code and branching to it, allowing
> the X86 CPU to do any optimisations it can while running native code ?

   By example, VEST does some of both.  On first pass it "compiles" what
   it can, using the original instructions as "source".  What it can't
   "compile" it will interpret at run time.  The resulting code may not
   be optimal, so it has a feedback mechanism to improve performance over 
   first guess.

In article <k0otgd$tju$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:

> A good question is, "is an emulated Alpha surperior to an emulated VAX?", all 
> else being equal?  I'd be interested to know.

   Only in that DEC made the stupid decision to split the source pool
   when they went from VAX to Alpha, so many features were never ported
   back to VAXen, and there are some that require 64 bit.

Bob Koehler wrote:
> In article <k0lo3u$guc$1@usenet01.boi.hp.com>, Keith Parris <keithparris_deletethis@yahoo.com> writes:
> 
>> No changes would 
>> be required in OpenVMS I64 code for it to run inside such an environment.
> 
>    And no performance would be achieved.  x86 isn't yet fast enough and
>    IA64 isn't slow enough for x86 to emulate IA64 at near IA64 hardware
>    speeds.

It's not just the CPUs and performance.  It's about device support and such.  As 
an example, my VAXs and some of the Alphas use 50 pin SCSI disks.  The last one 
of those I saw was in the clutches of a Dodo bird.

So an important issue is hardware support for available hardware.  For VAX, that 
would include PCI support in the OS, and HW implementing PCI, and S-ATA, and ... 
  Today.  Tomorrow, who knows.

That is one feature of the emulators, as long as they can run on current 
hardware, you're not faced with possible extinction every moment.

>    Like emulating VAXen on modern chips, it could get there, some day.
>    But if someone had decided to keep making VAXen, I suspect they'd
>    be using modern processes and clock speeds, and VAX emulators wouldn't
>    be running on chips with so much advantage that the emulation beats
>    hardware speed.

You bet.  It's an interesting question how fast an N-VAX or descendant processor 
would run at 35 nm.

>    In the intervening years, Alpha was one hot chip, and IA64 wasn't
>    bad.  Where would IA64 customers go in the meantime for VMS at
>    competitive performance?
> 

Bob Koehler wrote:
> In article <k0otgd$tju$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
> 
>> A good question is, "is an emulated Alpha surperior to an emulated VAX?", all 
>> else being equal?  I'd be interested to know.
> 
>    Only in that DEC made the stupid decision to split the source pool
>    when they went from VAX to Alpha, so many features were never ported
>    back to VAXen, and there are some that require 64 bit.
> 

Seems like nobody wants to answer the question that was asked ....

On Mon, 2012-08-20 at 17:34 -0400, David Froble wrote:

> You bet.  It's an interesting question how fast an N-VAX or descendant
> processor would run at 35 nm.=20

No one makes Alpha chips any more, so it would be far more interesting
to see how well these could work at the 32 nm process node. VAXs are
strictly 32 bit architecture.=20
--=20
Tactical Nuclear Kittens

The debate isn't how to emulate VAX. This has been done, and customers
who still rely on VAX know that VAXen have not bene produced since last
century, and that VAX/VMS hasn't been updated in about a decade.

VAX customers will continue unchanged because the products they rely on
(VAX and VAX/VMS) have been EOLed long ago.  They remained on VAX
despite the option to migrate to Alpha (some because it is an embedded
solution part of a bigger "box" (such as a paper mill), and others
because they rely on software killed by Palmer and not ported to Alpha
and others still have a VAX running for one last application with all of
the rest having been ported to other platforms.

The same will likely happen to both Alpha and IA64 VMS customers with
the difference being that there won't be a clear upgrade path to a new
platform as there was between VAX and Alpha and between Alpha and IA64.

returning to VAX is just not an option. While Alpha and IA64 VMS have a
subset of the original VAX/VMS applications portfolio, the apps they
have are far more modern and not available on VAX/VMS. (especially appls
that do require 64 bits).

How customers deal with the EOL of IA64 and VMS will depend on what sort
of programme HP announces (similar to Alpha Retain Trust when Alpha was
murdered).

Will HP make it easy to get extra VMS licences to grow capacity by
adding some more nodes to a cluster (buying IA64s second hand), or will
HP want to push customers to consolidate multiple VMS instances into
fewer that run emulated on an Odyssey 8086 mainframe ?

HP would be tempted to do the later in order to shore up sales of its
Odyssey mainframes.


There are far too many variables at this point to know how customers
will react. It all depends on what sort of "IA64 retain trust" programme
HP announces when it acknowledges the EOL of IA64 and VMS.


Unless HP announces a progressive port of VMS to x86 (module by module,
a bit like how Apple did it between 68l and PowerPC), the provision of
an emulator means that VMS will be declared mature and that HP expects
VMS custoemrs to first migrate their high CPU/capacity applications to
another platform and eventually move what is left of VMS on emulation
until that too has been migrated.

I don't think that performance will be all that important.

On Aug 21, 12:15=A0am, Single Stage to Orbit <alex.bu...@munted.eu>
wrote:
> On Mon, 2012-08-20 at 17:34 -0400, David Froble wrote:
> > You bet. =A0It's an interesting question how fast an N-VAX or descendan=
t
> > processor would run at 35 nm.
>
> No one makes Alpha chips any more, so it would be far more interesting
> to see how well these could work at the 32 nm process node. VAXs are
> strictly 32 bit architecture.
> --
> Tactical Nuclear Kittens

"VAXs are strictly 32 bit architecture."

x86 was "strictly 32 bit" too, according to Intel not all that long
ago. And then when AMD64 came out, Intel had to stop saying x86 was
"strictly 32 bit", and had to follow AMD's lead instead, leaving
Intel's proposed "industry standard 64bit" IA64 in the long grass
while AMD64 (and its Intel clone) takes over the world.

Mind you, if a miraculous resurrection were to occur, Alpha would
still seem to me like the more sensible choice rather than VAX. Not
that it matters much. For comp.os.vms it should be the software that
matters most, not The Chip Inside (tm).

On Mon, 20 Aug 2012 17:34:01 -0400, David Froble wrote:

> It's not just the CPUs and performance.  It's about device support and
> such.  As an example, my VAXs and some of the Alphas use 50 pin SCSI
> disks.  The last one of those I saw was in the clutches of a Dodo bird.

Hehe, there's a parallel somewhere here, given that fodos are extinct 
because they were shot for no reason except folks enjoyed shooting them.
 
> So an important issue is hardware support for available hardware.  For
> VAX, that would include PCI support in the OS, and HW implementing PCI,
> and S-ATA, and ...
>   Today.  Tomorrow, who knows.
> 
> That is one feature of the emulators, as long as they can run on current
> hardware, you're not faced with possible extinction every moment.

Yep.  I'm running both VAX and Alpha VMS here on a combination of SATA 
and USB disks, a USB keyboard, with a digital video connection (i.e. not 
a traditional VGA cable).

-- 
Paul Sture

On Mon, 20 Aug 2012 12:40:39 -0500, Bob Koehler wrote:

> In article <k0otgd$tju$1@dont-email.me>, David Froble
> <davef@tsoft-inc.com> writes:
> 
>> A good question is, "is an emulated Alpha surperior to an emulated
>> VAX?", all else being equal?  I'd be interested to know.
> 
>    Only in that DEC made the stupid decision to split the source pool
>    when they went from VAX to Alpha, so many features were never ported
>    back to VAXen, and there are some that require 64 bit.

I would call it unfortunate rather than stupid.  I am sure there were 
corners of code best left behind in getting a port out on time and on 
budget.

-- 
Paul Sture

On Tue, 21 Aug 2012 00:46:41 -0700, John Wallace wrote:

> x86 was "strictly 32 bit" too, according to Intel not all that long ago.
> And then when AMD64 came out, Intel had to stop saying x86 was "strictly
> 32 bit", and had to follow AMD's lead instead, leaving Intel's proposed
> "industry standard 64bit" IA64 in the long grass while AMD64 (and its
> Intel clone) takes over the world.

It still faintly amuses me that where 32 bit and 64 bit downloads of the 
same software are available, the 64 bit version has AMD64 in the name.

-- 
Paul Sture

In article <g17cg9-03k2.ln1@news1.chingola.ch>, Paul Sture <nospam@sture.ch> writes:
> 
> I would call it unfortunate rather than stupid.  I am sure there were 
> corners of code best left behind in getting a port out on time and on 
> budget.

   The kind of short-term, bottom-line thinking that's been sinking
   companies forever.

On Tue, 21 Aug 2012 08:50:21 -0500, Bob Koehler wrote:

> In article <g17cg9-03k2.ln1@news1.chingola.ch>, Paul Sture
> <nospam@sture.ch> writes:
>> 
>> I would call it unfortunate rather than stupid.  I am sure there were
>> corners of code best left behind in getting a port out on time and on
>> budget.
> 
>    The kind of short-term, bottom-line thinking that's been sinking
>    companies forever.

Well yes.  But there were also a lot of folks depending on the way
VAX/VMS worked.  I can imagine there were instances where updating the 
code could have broken stuff that worked before.  That involves risk 
control and somebody somewhere had to make that call.

There's always a compromise.

-- 
Paul Sture

Paul Sture <nospam@sture.ch> wrote:
> On Tue, 21 Aug 2012 00:46:41 -0700, John Wallace wrote:

>> x86 was "strictly 32 bit" too, according to Intel not all that long ago.
>> And then when AMD64 came out, Intel had to stop saying x86 was "strictly
>> 32 bit", and had to follow AMD's lead instead, leaving Intel's proposed
>> "industry standard 64bit" IA64 in the long grass while AMD64 (and its
>> Intel clone) takes over the world.

> It still faintly amuses me that where 32 bit and 64 bit downloads of the 
> same software are available, the 64 bit version has AMD64 in the name.

Among others, it helps avoid the confusion of IA64.

But the architecture originated from AMD, so it seems reasonable
that they name it.

-- glen

In article <1chcg9-03k2.ln1@news1.chingola.ch>, Paul Sture <nospam@sture.ch> writes:
> 
> There's always a compromise.

   There are also CM systems and conditional compilations.  Which means
   the genreated binary need not change.

Single Stage to Orbit wrote:
> On Mon, 2012-08-20 at 17:34 -0400, David Froble wrote:
> 
>> You bet.  It's an interesting question how fast an N-VAX or descendant
>> processor would run at 35 nm. 
> 
> No one makes Alpha chips any more, so it would be far more interesting
> to see how well these could work at the 32 nm process node. VAXs are
> strictly 32 bit architecture. 

I fail to understand what 32 bit or 64 bit has to do with speculation of what a 
past architecture might do with a modern process size ?

Yes, Alpha might be good too, but that wasn't the question.

On Tue, 21 Aug 2012 16:45:14 +0000, glen herrmannsfeldt wrote:

> Paul Sture <nospam@sture.ch> wrote:
>> On Tue, 21 Aug 2012 00:46:41 -0700, John Wallace wrote:
> 
>>> x86 was "strictly 32 bit" too, according to Intel not all that long
>>> ago.
>>> And then when AMD64 came out, Intel had to stop saying x86 was
>>> "strictly 32 bit", and had to follow AMD's lead instead, leaving
>>> Intel's proposed "industry standard 64bit" IA64 in the long grass
>>> while AMD64 (and its Intel clone) takes over the world.
> 
>> It still faintly amuses me that where 32 bit and 64 bit downloads of
>> the same software are available, the 64 bit version has AMD64 in the
>> name.
> 
> Among others, it helps avoid the confusion of IA64.
> 
> But the architecture originated from AMD, so it seems reasonable that
> they name it.

That makes sense.  It represents a gentle reminder that Intel aren't the 
only name in the game :-)

-- 
Paul Sture

On Tue, 2012-08-21 at 13:50 -0400, David Froble wrote:
> > No one makes Alpha chips any more, so it would be far more
> interesting
> > to see how well these could work at the 32 nm process node. VAXs are
> > strictly 32 bit architecture.=20
>=20
> I fail to understand what 32 bit or 64 bit has to do with speculation
> of what a past architecture might do with a modern process size ?
>=20
> Yes, Alpha might be good too, but that wasn't the question.=20

32 bit is limited to a maximum of 4GB. One won't be able to do a lot
with that with today's software requirements.
--=20
Tactical Nuclear Kittens

On 8/21/2012 1:29 PM, Bob Koehler wrote:
> In article <1chcg9-03k2.ln1@news1.chingola.ch>, Paul Sture <nospam@sture.ch> writes:
>>
>> There's always a compromise.
>
>     There are also CM systems and conditional compilations.  Which means
>     the genreated binary need not change.
>

genreated???

Don't you have a spelling checker?
Proofread before hitting "Send".

> genreated???

   What could be more annoying than a posting with a simple
transposition error?   Hmmm.  Let me think.  Perhaps a
posting with no relevant content complaining about one?
Yeah, that would do it.  In a forum where most of the
participants can't seem to master the difference between
"lose" and "loose", a higher complaint threshold would seem
to be called for.

> Don't you have a spelling checker?

   Don't you have a life?

> Proofread before hitting "Send".

   Think before hitting "Send"?

Single Stage to Orbit wrote:
> On Tue, 2012-08-21 at 13:50 -0400, David Froble wrote:
>>> No one makes Alpha chips any more, so it would be far more
>> interesting
>>> to see how well these could work at the 32 nm process node. VAXs are
>>> strictly 32 bit architecture. 
>> I fail to understand what 32 bit or 64 bit has to do with speculation
>> of what a past architecture might do with a modern process size ?
>>
>> Yes, Alpha might be good too, but that wasn't the question. 
> 
> 32 bit is limited to a maximum of 4GB. One won't be able to do a lot
> with that with today's software requirements.

1) the question wasn't about address space

2) it depends upon the software.  Weendoze bloatware might be an issue

3) There have been systems that have been able to handle more memory than their 
address size.  PDP-11, x86, ....

In article <RN6dnSSLxdwKmanNnZ2dnUVZ_o6dnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Don't you have a spelling checker?

   Not where I am doing news.

> Proofread before hitting "Send".

   No.  Usenet is to informal for me to be bothered with that.  Go pick
   somebody else's nits.
 

On Aug 21, 4:58=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> On 8/21/2012 1:29 PM, Bob Koehler wrote:
>
> > In article <1chcg9-03k2....@news1.chingola.ch>, Paul Sture <nos...@stur=
e.ch> writes:
>
> >> There's always a compromise.
>
> > =A0 =A0 There are also CM systems and conditional compilations. =A0Whic=
h means
> > =A0 =A0 the genreated binary need not change.
>
> genreated???
>
> Don't you have a spelling checker?
> Proofread before hitting "Send".

That should be: Proofread before hitting "Send."

Ain't nobody gots no good english around here? ;-)

Murphy's Law of Karma: If you belittle someone for making a mistake,
you will soon thereafter make a similar or worse mistake.

> That should be: Proofread before hitting "Send."

   Right.  Because adhering to literary quotation conventions
in a technical context is _so_ much more important than
conveying accurate information.  Compare, for example:

   There are only integer values in the statement, "J = 10".
   There are only integer values in the statement, "J = 10."


> "too", not "to".

   Piling on is so unseemly.  Is this Make Fun of the
Handicapped Week?


   Has anyone else noticed that when the number of postings
in a thread here hits about thirty, the useful-information
content pretty much vanishes?

Steven Schweda wrote:
>> genreated???
> 
>    What could be more annoying than a posting with a simple
> transposition error?   Hmmm.  Let me think.  Perhaps a
> posting with no relevant content complaining about one?
> Yeah, that would do it.  In a forum where most of the
> participants can't seem to master the difference between
> "lose" and "loose", a higher complaint threshold would seem
> to be called for.
> 
>> Don't you have a spelling checker?
> 
>    Don't you have a life?
> 
>> Proofread before hitting "Send".
> 
>    Think before hitting "Send"?

Stay in your respective corners until the bell rings ....

"Stephen Hoffman" <seaohveh@hoffmanlabs.invalid> wrote in message 
news:k0jiru$7rs$1@dont-email.me...
> On 2012-08-16 19:21:30 +0000, John Wallace said:
>
>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>> OpenVMS.Org are looking to collect and confirm some information about 
>>> OpenVMS users and usage. Please take a few minutes to complete this 13 
>>> question poll. Your input is 
>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>
>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>> Machine in a production environment"
>>
>> ?
>>
>> If that is intended to read as it is written, then it might be helpful
>> to expand on the concept a bit (a linked page? or is the Wikipedia
>> article sufficient?), for the benefit of those VMS folk who until now
>> have had no interest in what's been available on IA64.
>
> As written, that question is quite confusing.  Or the questioner is 
> confused.

Just like HP is confused.
If the poll is in the field at the behest of HP, then it's clearly 
indicative of HP's inability to communicate anything coherently - strategy, 
marketing, advertising - to its prospective or existing customers. 

On 9/3/2012 10:56 PM, John Smith (who cares if I'm the one @ HP - if 
here's even still there) wrote:
> "Stephen Hoffman" <seaohveh@hoffmanlabs.invalid> wrote in message
> news:k0jiru$7rs$1@dont-email.me...
>> On 2012-08-16 19:21:30 +0000, John Wallace said:
>>
>>> On Aug 16, 2:37 pm, Ian Miller <g...@uk2.net> wrote:
>>>> OpenVMS.Org are looking to collect and confirm some information about
>>>> OpenVMS users and usage. Please take a few minutes to complete this 13
>>>> question poll. Your input is
>>>> valuable.http://www.openvms.org/pages.php?page=Quick-Poll
>>>
>>> "would you use OpenVMS I64 running on x86 using an Integrity Virtual
>>> Machine in a production environment"
>>>
>>> ?
>>>
>>> If that is intended to read as it is written, then it might be helpful
>>> to expand on the concept a bit (a linked page? or is the Wikipedia
>>> article sufficient?), for the benefit of those VMS folk who until now
>>> have had no interest in what's been available on IA64.
>>
>> As written, that question is quite confusing.  Or the questioner is
>> confused.
>
> Just like HP is confused.
> If the poll is in the field at the behest of HP, then it's clearly
> indicative of HP's inability to communicate anything coherently - strategy,
> marketing, advertising - to its prospective or existing customers.
>
>

Was H-P EVER known for its ability to communicate?

I concluded many years ago that H-P's web site was useless until you 
used Google to search it.  H-P's search engine will find each occurrence 
of "X".  If you want to learn ABOUT "X", use Google to search the H-P site.

John Smith (who cares if I'm the one @ HP - if here's even still there)
wrote:

> If the poll is in the field at the behest of HP, then it's clearly 
> indicative of HP's inability to communicate anything coherently - strategy, 
> marketing, advertising - to its prospective or existing customers. 

I believe that HP's strategy is quite clear and well defined. But to
implement it properly, customers must not know what the strategy really
is until HP has all the pieces of the puzzle ready otherwise it would
prematurely set in motion customer churn without HP being able to
provide options.

HP may be using those vague questions simply to gauge enterprise
customers readyness to hear the real future for IA64 and its operating
systems.

Since HP bought Compaq, HP has had a very cohesive and constant message
to VMS customers.  It basically said that "'we'll support the existing
customer base for however long they need, but expect them to eventually
migrate to something else".

And HP has learned from all the platform terminations (MPE, Tru-64,
Alpha, PA-Risc) and knows not to repeat the premature Alpha murder
before replacement platform was ready.

HP didn't go about signing billion dollar contracts to buy Intel's
silence and pretend all was well with IA64 without having a very clear
plan. And how they stretched the releases to make IA64 appear to have a
longer life for the same amount of money was actually quite smart.


I suspect that the board level strategies involving billions of dollars
are much smarter than HP's abilities to sell screws to Mr VAXman.

I may not agree with HP's strategy, but I do not underestimate them.

On 2012-09-05 15:33:47 +0000, Paul Sture said:

> P.S. Can anyone remember what CSR stands for?  I tried Mr Bing and that
> came up with Certificate Signing Request and various organisation names.

Control and Status Register.  Also sometimes known as Can't Set Right.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On Wed, 05 Sep 2012 12:23:23 -0400, Stephen Hoffman wrote:

> On 2012-09-05 15:33:47 +0000, Paul Sture said:
> 
>> P.S. Can anyone remember what CSR stands for?  I tried Mr Bing and that
>> came up with Certificate Signing Request and various organisation
>> names.
> 
> Control and Status Register.  Also sometimes known as Can't Set Right.

Thanks.  FWIW it wasn't until many years later when configuring a tape 
drive on an 11/750 that I learnt how to translate the dip switch settings 
on a controller to a CSR address.  Once I saw it I immediately understood 
why they were quoted as octal numbers.

-- 
Paul Sture

On 2012-09-06 12:54:32 +0000, Johnny Billquist said:

> On 2012-09-06 14:04, Simon Clubley wrote:
>> 
>> In addition, one limitation on memory mapped registers is that they must
>> generally (at least on the devices I've used over the last few years) be
>> accessed as a atomic operation in units of the register size on the
>> register address boundary. In other words, no byte or (16 bit) word sized
>> operations on a longword sized register.
> 
> That was definitely possible on a PDP-11, and I believe the VAX as well.
> It might be a combination of CPU capabilities and bus design if it is 
> possible or not. I know of some modern machines where what you write is 
> correct, but I just wanted to point out the counter example. :-)
> Old and not that relevant in todays computing...

And Alpha, VAX and PDP-11 *are* relevent to today's computing?  Or VMS, 
in the broader market, for that matter?

Specific I/O space references do require word or longword alignment on 
VAX, and transfer alignment depends on the bus.

Chapter 5 here 
<http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_vax_sup_gd.pdf> 
has details of what's (not) allowed on VAX.

The Alpha CRAMs were also sensitive to alignment, but that's discussed 
in a different manual.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-06 15:28, Stephen Hoffman wrote:
> On 2012-09-06 12:54:32 +0000, Johnny Billquist said:
>
>> On 2012-09-06 14:04, Simon Clubley wrote:
>>>
>>> In addition, one limitation on memory mapped registers is that they must
>>> generally (at least on the devices I've used over the last few years) be
>>> accessed as a atomic operation in units of the register size on the
>>> register address boundary. In other words, no byte or (16 bit) word
>>> sized
>>> operations on a longword sized register.
>>
>> That was definitely possible on a PDP-11, and I believe the VAX as well.
>> It might be a combination of CPU capabilities and bus design if it is
>> possible or not. I know of some modern machines where what you write
>> is correct, but I just wanted to point out the counter example. :-)
>> Old and not that relevant in todays computing...
>
> And Alpha, VAX and PDP-11 *are* relevent to today's computing?  Or VMS,
> in the broader market, for that matter?

I think I was trying to day that they are *not* that relevant today.

> Specific I/O space references do require word or longword alignment on
> VAX, and transfer alignment depends on the bus.
>
> Chapter 5 here
> <http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_vax_sup_gd.pdf>
> has details of what's (not) allowed on VAX.

I think that pretty much covers what I said, but in a much more generic 
and complete form.

> The Alpha CRAMs were also sensitive to alignment, but that's discussed
> in a different manual.

I avoided the Alpha explicitly, since the first generation didn't even 
have any instruction to access anything smaller than a longword, if I 
remember right.

	Johnny

Stephen Hoffman wrote:

> Specific I/O space references do require word or longword alignment on 
> VAX, and transfer alignment depends on the bus.

Out of curiosity, had Digital decided to stay on VAX, perhaps stretching
it to 64 bits and added PCI bus support, would the PCI stuff have also
been stuck wth the CSR architecture ? Or could they have rewritten a new
way for VMS and VAX to deal with peripherals that was more modern ?

Or was the whole IO system for VMS so tied to the CSR way of doing
things on VAX that it absolutely could not e changed ?

On 2012-09-06 17:13:47 +0000, JF Mezei said:

> Stephen Hoffman wrote:
> 
>> Specific I/O space references do require word or longword alignment on
>> VAX, and transfer alignment depends on the bus.
> 
> Out of curiosity, had Digital decided to stay on VAX, perhaps stretching
> it to 64 bits and added PCI bus support, would the PCI stuff have also
> been stuck wth the CSR architecture ? Or could they have rewritten a new
> way for VMS and VAX to deal with peripherals that was more modern ?
> 
> Or was the whole IO system for VMS so tied to the CSR way of doing
> things on VAX that it absolutely could not e changed ?

As was discussed in an earlier thread, an operating system generally 
exists to abstract these and other constructs and details; only the 
folks writing drivers and low-level OS giblets generally need to deal 
with physical addressing and memory maps, registers, DMA and PIO, and 
the rest of bizarre world that is device-level I/O.

VAX and VMS supported a variety of very different buses.  Off the top, 
SBI, CMI, Unibus, MASSBUS, BI, XMI, the rarely-seen Mbus, and others.  
And arguably, the MA780, CI and DSSI, and some other odd giblets could 
fit onto this list, too.

Whether a particular bus can be supported depends on how much existing 
software you're willing to break, and adding a different bus will 
require some work in existing device drivers, and can require new 
device drivers.

And FWIW, CSRs exist on Alpha and Itanium, too.


-- 
Pure Personal Opinion | HoffmanLabs LLC

Johnny Billquist <bqt@softjar.se> wrote:

(snip)
> I avoided the Alpha explicitly, since the first generation didn't even 
> have any instruction to access anything smaller than a longword, if I 
> remember right.

Well, it had instruction sequences to do it. But yes, on the memory bus
you only see longword or quadword accesses.

-- glen

Stephen Hoffman wrote:

> And FWIW, CSRs exist on Alpha and Itanium, too.

Is the concept of CSR pretty much standard across all operating systems,
and all buses ?

What about the vectors that were the second configurable items in Q-Bus
boards ? re those also common across all devices/operating systems and
buses ?

Let me rephrase the above: are the concepts used in Q-BUS basically
common to all devices/buses even today, with the major difference the
way they now automatically configure ?

On 2012-09-06 18:09:23 +0000, glen herrmannsfeldt said:

> Johnny Billquist <bqt@softjar.se> wrote:
> 
> (snip)
>> I avoided the Alpha explicitly, since the first generation didn't even
>> have any instruction to access anything smaller than a longword, if I
>> remember right.
> 
> Well, it had instruction sequences to do it. But yes, on the memory bus
> you only see longword or quadword accesses.

The byte-word extensions were added in EV56.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-06 18:31:23 +0000, JF Mezei said:

> Stephen Hoffman wrote:
> 
>> And FWIW, CSRs exist on Alpha and Itanium, too.
> 
> Is the concept of CSR pretty much standard across all operating systems,
> and all buses ?

Mapping I/O devices into physical address space is quite common, but I 
don't know that it's universal.

> What about the vectors that were the second configurable items in Q-Bus
> boards ? re those also common across all devices/operating systems and
> buses ?

Most I/O devices can generate interrupts when the board wants or needs 
attention, though the implementations and capabilities do differ.

> Let me rephrase the above: are the concepts used in Q-BUS basically
> common to all devices/buses even today, with the major difference the
> way they now automatically configure ?

At sufficient levels of abstraction, humans are indistinguishable from 
your average brown bear, too.
Big; four articulated limbs and a bone-clad brain-case; usually grumpy; 
eats most anything this side of rocks; yeah, that's a match...


-- 
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote:

> At sufficient levels of abstraction, humans are indistinguishable from 
> your average brown bear, too.
> Big; four articulated limbs and a bone-clad brain-case; usually grumpy; 
> eats most anything this side of rocks; yeah, that's a match...

The above may apply to comp.sys.vms users, but not necessarily to all
humans :-)

In article <5048d9cd$0$1530$c3e8da3$92d0a893@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Stephen Hoffman wrote:
>
>> Specific I/O space references do require word or longword alignment on 
>> VAX, and transfer alignment depends on the bus.
>
>Out of curiosity, had Digital decided to stay on VAX, perhaps stretching
>it to 64 bits and added PCI bus support, would the PCI stuff have also
>been stuck wth the CSR architecture ? Or could they have rewritten a new
>way for VMS and VAX to deal with peripherals that was more modern ?
>
>Or was the whole IO system for VMS so tied to the CSR way of doing
>things on VAX that it absolutely could not e changed ?

You never got off of a MicroVAX-II, did you?


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

VAXman- @SendSpamHere.ORG wrote:

> You never got off of a MicroVAX-II, did you?

The DS10L has only one slot and I never ad to configure the cards
because Dave Turner at Island Co had done it for me and I am not sure
one even has to configure them for the PCI that DL10L has.

VAXman- @SendSpamHere.ORG wrote:

> You never got off of a MicroVAX-II, did you?

And on my Macs, with PCI-Express, I know that position of the card can
be detected by the system. I have 2 graphic cards and depending on how
they are inserted, one is the first screen and the other not.

On 2012-09-06 20:25:14 +0000, JF Mezei said:

> VAXman- @SendSpamHere.ORG wrote:
> 
>> You never got off of a MicroVAX-II, did you?
> 
> The DS10L has only one slot and I never ad to configure the cards
> because Dave Turner at Island Co had done it for me and I am not sure
> one even has to configure them for the PCI that DL10L has.

You put the card in the PCI slot and boot, and (if it's a 
correctly-functioning, supported PCI widget) get on with dealing with 
VMS or the applications or whatever else was on the agenda.

PCI (and PCI-X and PCIe) have a vendor and card identification scheme 
(the so-called PCI ID), which means that the VMS device configuration 
software can map and select and load the appropriate drivers 
<http://labs.hoffmanlabs.com/node/599>, and without the shenanigans 
associated with the Q-bus and Unibus CSR and vector configurations.


-- 
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2012-09-06 18:31:23 +0000, JF Mezei said:

(snip) 
>> Is the concept of CSR pretty much standard across all operating systems,
>> and all buses ?

> Mapping I/O devices into physical address space is quite common, but I 
> don't know that it's universal.

Intel processors, at least 8080 descendants, have a separate I/O space.
IN and OUT instructions read/write to I/O space.

But the idea of reading/writing commands and status to I/O
devices is pretty much standard. How you do it isn't.

>> What about the vectors that were the second configurable items in Q-Bus
>> boards ? re those also common across all devices/operating systems and
>> buses ?

> Most I/O devices can generate interrupts when the board wants or needs 
> attention, though the implementations and capabilities do differ.

Some systems use the position of the device on the bus to specify
interrupt priority. For ISA, each interrupt has a bus line, and
pulls it low to request an interrupt. The priority is based on
which IRQ line is used. Also, ISA uses edge triggered interrupts,
complicating sharing an IRQ line. 

>> Let me rephrase the above: are the concepts used in Q-BUS basically
>> common to all devices/buses even today, with the major difference the
>> way they now automatically configure ?

Close enough that it should be possible to build an adapter 
between some other buses. Some fairly simply, some much more
complicated. 

Well, to start there are synchronous and asynchronous buses. 
Then there are some with more than two addressing spaces.
VME has different addressing space for different address and
data widths. 

> At sufficient levels of abstraction, humans are 
> indistinguishable from your average brown bear, too.
> Big; four articulated limbs and a bone-clad brain-case; usually grumpy; 
> eats most anything this side of rocks; yeah, that's a match...

-- glen

Stephen Hoffman wrote:

> PCI (and PCI-X and PCIe) have a vendor and card identification scheme 
> (the so-called PCI ID), which means that the VMS device configuration 
> software can map and select and load the appropriate drivers 
> <http://labs.hoffmanlabs.com/node/599>, and without the shenanigans 
> associated with the Q-bus and Unibus CSR and vector configurations.


Internally though, does PCI still work with CSR  and vectors (no matter
how they are called) ?

On 2012-09-06, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> Stephen Hoffman wrote:
>
>> And FWIW, CSRs exist on Alpha and Itanium, too.
>
> Is the concept of CSR pretty much standard across all operating systems,
> and all buses ?
>

Memory mapped I/O is a attribute of the the CPU architecture, not the
operating system, but yes it's extremely common across architectures
ranging from 8-bit PICs/AVRs, through to the ARM MCUs (low and high end)
and on to the desktop/server processors, although the x86 does have it's
I/O port based infrastructure as well.

> What about the vectors that were the second configurable items in Q-Bus
> boards ? re those also common across all devices/operating systems and
> buses ?
>

Once again, it's a attribute of the CPU architecture, not the OS and
while vectors are present in everything I've used, the capability varies
heavily by architecture. For example, in the 8-bit world, the super-crappy
PICs have very limited vectoring support, while the AVRs have a _much_
more elegant setup.

By the time you get to the ARM world (both low and high end ARM MCUs) it's
very common to have interrupt vectoring priorities which are program
definable and also support priority based fully nested interrupts.

I assume you are already familiar with what is available in traditional
desktop/server processor architectures.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-09-06, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> Stephen Hoffman wrote:
>
>> PCI (and PCI-X and PCIe) have a vendor and card identification scheme 
>> (the so-called PCI ID), which means that the VMS device configuration 
>> software can map and select and load the appropriate drivers 
>> <http://labs.hoffmanlabs.com/node/599>, and without the shenanigans 
>> associated with the Q-bus and Unibus CSR and vector configurations.
>
>
> Internally though, does PCI still work with CSR  and vectors (no matter
> how they are called) ?

Yes, that's part of it, but it's not that simple. I've just had a quick
look on Wikipedia for some conceptual stuff I can point you to and the
PCI article there seems to be a good writeup:

http://en.wikipedia.org/wiki/Conventional_PCI

BTW, another part of the puzzle you are not considering is the role
of DMA based transfers.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Sep 6, 3:26=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> VAXman- @SendSpamHere.ORG wrote:
> > You never got off of a MicroVAX-II, did you?
>
> And on my Macs, with PCI-Express, I know that position of the card can
> be detected by the system. I have 2 graphic cards and depending on how
> they are inserted, one is the first screen and the other not.

Same with Alphas that had multiple PCI/PCI-X slots.  The order of the
cards affects the console names of the devices (most easily notices
with SCSI and ethernet cards).

On 2012-09-06 22:11:30 +0000, JF Mezei said:

> Stephen Hoffman wrote:
> 
>> PCI (and PCI-X and PCIe) have a vendor and card identification scheme
>> (the so-called PCI ID), which means that the VMS device configuration
>> software can map and select and load the appropriate drivers
>> <http://labs.hoffmanlabs.com/node/599>, and without the shenanigans
>> associated with the Q-bus and Unibus CSR and vector configurations.
> 
> 
> Internally though, does PCI still work with CSR  and vectors (no matter 
> how they are called) ?

Of course not!  It's all Unicorns and rainbows.  Computers are magic 
smoke containers.

But seriously...   None - zero - zilch - nada - of this stuff is 
relevant to application programs; this is all abstracted.

The more an application programmer codes to this level of the hardware 
implementation, the less portable the code will be.  Quite possibly 
less portable from one model of or family of VAX, Alpha or Itanium 
processor to another - even of the same architecture.

So if you really want to know about this stuff (on VMS), then read the 
device driver book: Writing VMS Device Drivers in C, and start digging 
around.  (The older editions of the driver books are still online 
<http://www.hp.com/go/openvms/doc>, but this particular book isn't.)  
But it might be better payback for you to spend your time learning 
about OS X kexts and drivers or some such 
<https://developer.apple.com/hardwaredrivers/> 
<https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/KernelProgramming.pdf> 
(and about x86-64 and ARM) given your platform migration plans.

And yes, from the perspective of VMS on most I/O buses (including PCI), 
device drivers tweak the CSRs if and when necessary, and the driver 
then waits around for something to happen; for the interrupts to arrive.

But for most folks (and particularly those that wish to maintain a 
semblance of sanity), let that "bag of drivers" that is the operating 
system deal with this stuff for you.  (Have you seen the grey hair and 
the bear-like grumpiness that some of us device-driver folks have?)



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-06 20:31, JF Mezei wrote:
> Stephen Hoffman wrote:
>
>> And FWIW, CSRs exist on Alpha and Itanium, too.
>
> Is the concept of CSR pretty much standard across all operating systems,
> and all buses ?

Yes.

> What about the vectors that were the second configurable items in Q-Bus
> boards ? re those also common across all devices/operating systems and
> buses ?

That is less so, but still pretty common. The vector thingy ties into 
how the processor handles interrupts. On Unibus and Q-bus, when a device 
requests an interrupt, and it gets acknowledged, as a part of the 
handshaking between the controller and the CPU, the controller is 
expected to put out a word, which the CPU reads in and do something 
with. On a PDP-11, it simply becomes a pointer to a chunk of memory 
where the CPU is supposed to find a new PC and PSW to use for the 
interrupt handler.

Other CPUs and buses can have other ways to identify the source of the 
interrupt, since that is really the question at the bottom here. It can 
be anything from just having a separate interrupt request signal per 
interface to just one common signal, and then having software poll all 
devices to find out which ones requested an interrupt.

Obviously both having one signal line per interface and just having one 
signal and a polling solution is less flexible than having an 
interrupting device present some kind of identifier to the CPU at the 
interrupt handshaking. But there are plenty of solutions and 
possibilities...

> Let me rephrase the above: are the concepts used in Q-BUS basically
> common to all devices/buses even today, with the major difference the
> way they now automatically configure ?

Yes. All devices have some sort of status and command registers. Some 
have a single, some have plenty.
The difference is actually how you address those registers, with things 
like the PDP-11, VAX and others having them mapped in normal memory 
space, and use the normal memory reference instructions to access them. 
The other variant you find are special instructions to access them, and 
in that case they are not in your normal memory space.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

So, a followup here:

Some have said that it all depends on the CPU acritecture and then there
is discussion of how interrupts and communications happen.

Are buses designed with a particular CPU in mind ? For insance, was PCI
designed with an interface compatile with the way the x86 expects to
communicate with devices ?

or are buses designed independently from CPUs with expectation that each
CPU architecture will develop its chipset to communicate with that bus ?

On 2012-09-07 04:14, JF Mezei wrote:
> So, a followup here:
>
> Some have said that it all depends on the CPU acritecture and then there
> is discussion of how interrupts and communications happen.

It's actually a result of the combination of bus and cpu. But on modern 
systems it can become even more complex, since you might have interrupt 
controllers sitting in the middle, which adapts one CPU to the behavior 
of another bus.

And that is just for interrupts. You also have the question on how to 
access control and status of the device. Which sometimes also requires 
various adaptations. But that is often less complex, since there are 
less ways that part is done, at a general level of view.

> Are buses designed with a particular CPU in mind ? For insance, was PCI
> designed with an interface compatile with the way the x86 expects to
> communicate with devices ?

Some are, some are not. And then you have controllers sitting in 
between, which adapts the two to each other, when their concepts mismatch.

> or are buses designed independently from CPUs with expectation that each
> CPU architecture will develop its chipset to communicate with that bus ?

Either. :-)

And of course, during all this, we have not touched on the third leg: DMA.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> So, a followup here:

> Some have said that it all depends on the CPU acritecture and then there
> is discussion of how interrupts and communications happen.

> Are buses designed with a particular CPU in mind ? For insance, was PCI
> designed with an interface compatile with the way the x86 expects to
> communicate with devices ?

Both. There are some specifically designed to be processor independent.
Others come from taking the processor signals and putting them on
a bus.

Remember the S-100 bus from the 8080 days? Designed by the original
Altair designer who got a good deal on 100 pin connectors. 

> or are buses designed independently from CPUs with expectation that each
> CPU architecture will develop its chipset to communicate with that bus ?

VME, I believe, was designed to be processor independent. 
I believe also PCI, though I haven't followed it so closely.

-- glen

Simon Clubley wrote 2012-09-07 00:13:

> Once again, it's a attribute of the CPU architecture, not the OS and
> while vectors are present in everything I've used, the capability varies
> heavily by architecture. For example, in the 8-bit world, the super-crappy
> PICs...

They are not. They (in particular the new enhanced midrange line
(PIC16F1xxx) are realy nice. I wrote a small demo for a 8x64 LED
display a week ago and the new index adressing modes and linear
memory addressing makes some tasks realy easy and fast.

Then there are the 16 and 32 bit (PIC24 and PIC32) that are not
att all like the older "PICs"...

AVR's are nice in there own way (in particular the dev.tools)
but the architecture as such is a bit weird.

Jan-Erik.

On 2012-09-07 02:14:06 +0000, JF Mezei said:

> So, a followup here:

Suggestion: try a computer architecture course, and not 
comp.os.we-know-the-old-gear?  
<https://courseware.stanford.edu/pg/courses/280977/ee282-spring-2012>, 
or similar.  There are probably some free courses on coursera or iTunes 
U or other such, too.

A business course or two can be helpful with the prospects here, too, 
as that knowledge can help seperate the usual sorts of fantasy and 
fiction from what can be achieved; to differentiate a {bus, system, 
computer architecture, whatever} that is technically possible from a 
design or a product that is viable in a commercial market.

> Some have said that it all depends on the CPU acritecture and then there
> is discussion of how interrupts and communications happen.

This is low-level stuff.   It's OS-level and driver-level.  That means 
it's whacky and weird, and that some of the provided specs or the 
provided documentation can be fictional.  It also means it's 
widget-specific, device-specific, processor-specific and usually 
vendor-specific.  Chipsets sometimes don't work, architectures have 
bugs, buses have wonkies, edge cases can abound, and each level does 
its best to mess up the higher levels, while each higher level does its 
best to hide all of the, um, errata lurking in the lower levels.

> 
> Are buses designed with a particular CPU in mind ? For insance, was PCI
> designed with an interface compatile with the way the x86 expects to
> communicate with devices ?

This is as much a business decision as a technical one.  Well, this is 
largely a business decision.  Wait, this is entirely a business 
decision.  When designing a bus, you're aiming for a particular target 
market, and factoring in the costs of the components to the systems 
vendors and to the folks making the I/O widgets, the speed of the bus, 
the compatibility across the target processor architectures, applicable 
patents and licenses, etc.  Whether you can harness the various pieces 
and parts and technology to work is secondary to the revenues.

Put another way, the engineering effort exists entirely to determine if 
the product is financially viable.

In the specific case of designing the PCI, you'd be a very huge fool to 
not design for reasonable {performance, price} compatibility with the 
dominant architecture in your target market for your new bus, and 
that's x86.

Again, having the best technology around or the coolest features is 
irrelevent - and a good way to lose money - if your product misses its 
target market.  (Well, barring that rare case where a vendor gets 
really lucky, and hit some other target market that you didn't know 
existed, and that's very rare.)

> or are buses designed independently from CPUs with expectation that each
> CPU architecture will develop its chipset to communicate with that bus ?

Some few buses undoubtedly are designed this way.  Mostly the buses you 
don't hear about, either because they're very specialized or deeply 
embedded in some other box, or those buses that are AD or research 
projects, or those buses that utterly fail in the market due to errors 
committed by the business folks or the engineers that were involved.

But unless you have a particular issue with the existing buses and can 
provide a substantially better solution, there's not much point in 
trying to replace PCIe 4.0 with something other than whatever PCIe 4.0 
eventually rolls out with.  Failing to hit the market is a good way 
to... wait for it... lose money.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-07, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
> Simon Clubley wrote 2012-09-07 00:13:
>
>> Once again, it's a attribute of the CPU architecture, not the OS and
>> while vectors are present in everything I've used, the capability varies
>> heavily by architecture. For example, in the 8-bit world, the super-crappy
>> PICs...
>
> They are not. They (in particular the new enhanced midrange line
> (PIC16F1xxx) are realy nice. I wrote a small demo for a 8x64 LED
> display a week ago and the new index adressing modes and linear
> memory addressing makes some tasks realy easy and fast.
>

Sorry, but they are.

On the 8-bit PICs you have a total of 2 interrupt vectors (low and high
priority) for the high end devices and only 1 interrupt vector for the
other devices. All devices vector via these 1 or 2 interrupts.
This means your interrupt handler has to look something like this:

void interrupt_handler()
	{
	if(uart_interrupt_bit_set)
		{
		uart_handler();
		}

	if(gpio_interrupt_bit_set)
		{
		gpio_handler();
		}

	if(timer_interrupt_bit_set)
		{
		timer_handler();
		}

	if(some_other_device_interrupt_bit_set)
		{
		some_other_device_handler();
		}
	}

In other words, _every_ time you take a interrupt, the handler has to poll
_all_ the device registers to find out which device needs attention.

By comparison, in the AVR (and any sane architecture), all the devices have
their own unique interrupt vectors, which means you can dispatch directly to 
the device specific handler without taking this crazy level of overhead.

Device specific vectors also make for nicely modular code as well. In order
to get modular code on the PIC18, I had to abstract out the interrupt handler
into it's own library and the device specific drivers register their own
handlers with this library. The global interrupt handler calls the registered
address for a handler if it gets a match while looking at the interrupt
status bits.

In other words, I am having to do in software what any sane architecture
already provides in hardware.

In addition to this, there are also other issues such as having only one
general purpose register (hence no gcc) as well as the banked memory
architecture.

> Then there are the 16 and 32 bit (PIC24 and PIC32) that are not
> att all like the older "PICs"...
>

That's why I made a point of only talking about the 8-bit PICs above.

I don't really know much about the PIC24 because (a) the only open source
compiler for it is Microchip's own gcc/binutils fork and (b) the PIC32
overlaps in capabilities, so I wasn't interested in investing time
finding out more about the PIC24.

From what I know about it however, it's basically a seriously grown up
version of the PIC18 architecture with the biggest flaws fixed. For
example, it has multiple interrupt vectors and multiple general purpose
registers.

The PIC32 however, is something completely different. The only
relationship it has to earlier PICs is that it has PIC in it's name and
what appears to look like the PIC24 device set built in. It's MIPS
core means it has a standard instruction set and also means it should be
possible to use a standard gcc build without having to use Microchip's
own build. The PIC32 is something I am very interested in looking at in
the future (when time permits :-)).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley wrote 2012-09-07 14:09:> On 2012-09-07, Jan-Erik Soderholm 
<jan-erik.soderholm@telia.com> wrote:
 >> Simon Clubley wrote 2012-09-07 00:13:
 >>
 >>> Once again, it's a attribute of the CPU architecture, not the OS and
 >>> while vectors are present in everything I've used, the capability varies
 >>> heavily by architecture. For example, in the 8-bit world, the super-crappy
 >>> PICs...
 >>
 >> They are not. They (in particular the new enhanced midrange line
 >> (PIC16F1xxx) are realy nice. I wrote a small demo for a 8x64 LED
 >> display a week ago and the new index adressing modes and linear
 >> memory addressing makes some tasks realy easy and fast.
 >>
 >
 > Sorry, but they are.

Well, maybe if you measure an architecture *only* by how
the interrupts works. I'm not. :-)


 > In other words, _every_ time you take a interrupt, the handler has to poll
 > _all_ the device registers to find out which device needs attention.

No, only until you get a match. And if you put the high frequency
interrupts first you'll get a match faster, on avarage.

 >
 > In addition to this, there are also other issues such as having only one
 > general purpose register...

Now, all GPR ("General Purpose Registers" or "RAM") works more or less
as 16 of the "registers" on the AVR. Most/all instructions works
in the same way against *all* memory. On the AVR you have (at least)
3 different types of "memory" with different instructions only
working against particular parts of the memory, a mess.

The fact that there is only one "Working register" (W or WREG)
is not a major issue since most aritm/logical/bit instructions
and so on works against the full range of available RAM anyway.
On the AVR you have load/store between "RAM" and "Registers"
to do anything (apart from load/store) on data in "RAM"...

On AVR, the indexed adressing mode (called "indirect") is only
available for load/store instructions. On PIC, indexed adressing
is available as an alternative adressing mode for *any* instruction.

E.g. you can INCF *any* RAM location using indexed adressing in
the PIC. On the AVR you have to LD from RAM to a "register", then
INC the register and finaly ST the register back to RAM.

You can't judge an architecture only from how interrupts works.


 > (hence no gcc) as well as the banked memory
 > architecture...

A much smaller issue then the many different memory types
(32 "Registers" split in two groups with some instructions
only working on one group, and "RAM" with only load/store
instructions working against it) in the AVR architecture.

And the "enhanced midrange" (PIC16F1xxx) has a linear addressing
area where all RAM can be accessed using *all* instructions
including inc/dec and bit set/clear/test instructions using a
linear addresse range without any banking at all.

Jan-Erik.

 >
 > Simon.
 >

On 2012-09-07 00:11, JF Mezei wrote:
> Stephen Hoffman wrote:
>
>> PCI (and PCI-X and PCIe) have a vendor and card identification scheme
>> (the so-called PCI ID), which means that the VMS device configuration
>> software can map and select and load the appropriate drivers
>> <http://labs.hoffmanlabs.com/node/599>, and without the shenanigans
>> associated with the Q-bus and Unibus CSR and vector configurations.
>
>
> Internally though, does PCI still work with CSR  and vectors (no matter
> how they are called) ?

Yes. I guess you should take a course in computer systems at a low 
level, or read some books.
It's really not that hard, or obscure. It's just that unless you write 
operating systems, or code that runs without an OS at all, you normally 
never need to know about these things.

But the short answer is that nothing really new have happened in this 
are in 50 years. A fantasy, new VAX, with a PCI bus would make 
absolutely no difference to 99% of VMS anyway. The one thing that would 
change is that you'd need device drivers that talk to devices on the PCI 
bus, which on a general level works no different than any other bus. 
Details might differ, and the VAX might have some support chip to adapt 
the CPU to the bus, since signalling and handshaking on different buses 
differ, but that is all hardware, and does not really affect the VAX 
directly. The device drivers are really the only thing that are 
affected, and it's not that the whole architecture in any way would be 
affected because of a new bus, since it's just another bus.

And before you ask, the VAX already uses adaptore (chips, or whole 
boards) to interface the CPU to the buses it do use. The CPU don't sit 
directly on anything except the cpu/system bus, and that bus normally 
don't have any peripherials on it, but only bus adapters.

	Johnny

On 2012-09-07 14:45, Jan-Erik Soderholm wrote:
> Simon Clubley wrote 2012-09-07 14:09:> On 2012-09-07, Jan-Erik Soderholm
> <jan-erik.soderholm@telia.com> wrote:
>  >> Simon Clubley wrote 2012-09-07 00:13:
>  >>
>  >>> Once again, it's a attribute of the CPU architecture, not the OS and
>  >>> while vectors are present in everything I've used, the capability
> varies
>  >>> heavily by architecture. For example, in the 8-bit world, the
> super-crappy
>  >>> PICs...
>  >>
>  >> They are not. They (in particular the new enhanced midrange line
>  >> (PIC16F1xxx) are realy nice. I wrote a small demo for a 8x64 LED
>  >> display a week ago and the new index adressing modes and linear
>  >> memory addressing makes some tasks realy easy and fast.
>  >>
>  >
>  > Sorry, but they are.
>
> Well, maybe if you measure an architecture *only* by how
> the interrupts works. I'm not. :-)

Jeez. You're not much for reading the whole context of a thread before 
commenting, are you? :-)

The source of this argument is the following statement:

>> What about the vectors that were the second configurable items in Q-Bus
>> boards ? re those also common across all devices/operating systems and
>> buses ?
>>
>
> Once again, it's a attribute of the CPU architecture, not the OS and
> while vectors are present in everything I've used, the capability varies
> heavily by architecture. For example, in the 8-bit world, the super-crappy
> PICs have very limited vectoring support, while the AVRs have a _much_
> more elegant setup.

Note how the comment about "super-crappy PICs" are about interrupt 
vectors... This whole thread if about interrupt vectors. Now, if you 
want to argue the various merits of other aspects of various chips, 
that's fine, but please start a new thread for it instead of subverting 
existing ones for that purpose... :-)

"super-crappy" might be a very subjective term, but used in the context 
of what kind of interrupt handling support they have, I don't see why an 
argument is needed.

"Have you come for a 10 minute argument, or for the full hour?"

	Johnny

Stephen Hoffman wrote:

> Suggestion: try a computer architecture course, and not
> comp.os.we-know-the-old-gear?

The computer architecture course I took at university dealt with And, Or
Nand, Nor gates, interface with memory, but not IO. And at the time, the
reference was the IBM 360/370 architecture.

The reason I ask is more historical. When DEC decided to use PCI with
teh Alpha, how much work did it have to do to adapt a bus that was
originally designed to live with x86 ?

Did DEC develop its own implementation of PCI that had the PCI specs on
the bus itself, but totally different way to talk to the CPU ? Or was it
able to use off-the-shelf chips that implement PCI and then tweaked
firmware on the CPU side to talk to that chip ?


There are now buses such as "Thunderbolt" when you can hook on various
adaptors. So a  ethernet driver that is expecting to talk to an ethernet
card ends up reaching the ethernet "card" via the thunderbolt, which
implies a thunderbolt driver that gets in between the ethernet driver
and the ethernet device.  Does the ethernet driver have to know it is
talking to another driver instead of another device, or does the
thunderbolt driver virtualise an ethernet card and the ethernet driver
thinks it is talking to a card ?

On 2012-09-07 20:36, JF Mezei wrote:
> Stephen Hoffman wrote:
>
>> Suggestion: try a computer architecture course, and not
>> comp.os.we-know-the-old-gear?
>
> The computer architecture course I took at university dealt with And, Or
> Nand, Nor gates, interface with memory, but not IO. And at the time, the
> reference was the IBM 360/370 architecture.
>
> The reason I ask is more historical. When DEC decided to use PCI with
> teh Alpha, how much work did it have to do to adapt a bus that was
> originally designed to live with x86 ?
>
> Did DEC develop its own implementation of PCI that had the PCI specs on
> the bus itself, but totally different way to talk to the CPU ? Or was it
> able to use off-the-shelf chips that implement PCI and then tweaked
> firmware on the CPU side to talk to that chip ?
>
>
> There are now buses such as "Thunderbolt" when you can hook on various
> adaptors. So a  ethernet driver that is expecting to talk to an ethernet
> card ends up reaching the ethernet "card" via the thunderbolt, which
> implies a thunderbolt driver that gets in between the ethernet driver
> and the ethernet device.  Does the ethernet driver have to know it is
> talking to another driver instead of another device, or does the
> thunderbolt driver virtualise an ethernet card and the ethernet driver
> thinks it is talking to a card ?

There is no "one" ethernet driver. There is more or less a separate 
ethernet driver for every different chip and card ever made...

Your terminology is strange. DEC didn't develop it's own implementation 
of PCI. PCI is a bus that is defined by a bunch of documents. You either 
adhere to it, or you don't. If you don't, when no PCI card might work. 
If you do, they should all work.
However, what you need are device drivers for all the cards on that bus 
which you expect to support, as well as some hardware that connects 
together your CPU with the bus. That includes such things as 
mapping/remapping of CSRs somewhere where your CPU can access them, some 
way to map/remap interrupts so that they work, and some way to map/remap 
DMA so that it works.
There are plenty of details in the bus adapter chips. DEC probably had 
to develop their own chip to get an Alpha to talk with devices on a PCI 
bus. But once that is done, it's mostly a question of some setup of that 
chip at boot time, and then do the device driver parts, which boils down 
to pretty normal code of manipulating a device, no matter which bus it 
sits on.

	Johnny

Johnny Billquist <bqt@softjar.se> wrote:

(snip, someone wrote)
>> The reason I ask is more historical. When DEC decided to use PCI with
>> teh Alpha, how much work did it have to do to adapt a bus that was
>> originally designed to live with x86 ?

(snip)
> There is no "one" ethernet driver. There is more or less a separate 
> ethernet driver for every different chip and card ever made...

> Your terminology is strange. DEC didn't develop it's own implementation 
> of PCI. PCI is a bus that is defined by a bunch of documents. You either 
> adhere to it, or you don't. If you don't, when no PCI card might work. 
> If you do, they should all work.

But many have ROM on board for a specific processor.

So, yes the host can read/write the registers but any onboard
BIOS ROM won't help any.

> However, what you need are device drivers for all the cards on that bus 
> which you expect to support, as well as some hardware that connects 
> together your CPU with the bus. That includes such things as 
> mapping/remapping of CSRs somewhere where your CPU can access them, some 
> way to map/remap interrupts so that they work, and some way to map/remap 
> DMA so that it works.

And even if there isn't ROM on board, someone has to write the
appropriate device driver for your CPU.

> There are plenty of details in the bus adapter chips. DEC probably had 
> to develop their own chip to get an Alpha to talk with devices on a PCI 
> bus. But once that is done, it's mostly a question of some setup of that 
> chip at boot time, and then do the device driver parts, which boils down 
> to pretty normal code of manipulating a device, no matter which bus it 
> sits on.

-- glen

On 2012-09-07 21:43, glen herrmannsfeldt wrote:
> Johnny Billquist <bqt@softjar.se> wrote:
>
> (snip, someone wrote)
>>> The reason I ask is more historical. When DEC decided to use PCI with
>>> teh Alpha, how much work did it have to do to adapt a bus that was
>>> originally designed to live with x86 ?
>
> (snip)
>> There is no "one" ethernet driver. There is more or less a separate
>> ethernet driver for every different chip and card ever made...
>
>> Your terminology is strange. DEC didn't develop it's own implementation
>> of PCI. PCI is a bus that is defined by a bunch of documents. You either
>> adhere to it, or you don't. If you don't, when no PCI card might work.
>> If you do, they should all work.
>
> But many have ROM on board for a specific processor.
>
> So, yes the host can read/write the registers but any onboard
> BIOS ROM won't help any.
>
>> However, what you need are device drivers for all the cards on that bus
>> which you expect to support, as well as some hardware that connects
>> together your CPU with the bus. That includes such things as
>> mapping/remapping of CSRs somewhere where your CPU can access them, some
>> way to map/remap interrupts so that they work, and some way to map/remap
>> DMA so that it works.
>
> And even if there isn't ROM on board, someone has to write the
> appropriate device driver for your CPU.

You can only say "you need a device driver" in so many ways... :-)

	Johnny

On Fri, 2012-09-07 at 14:36 -0400, JF Mezei wrote:
> The reason I ask is more historical. When DEC decided to use PCI with
> teh Alpha, how much work did it have to do to adapt a bus that was
> originally designed to live with x86 ?=20

PCI is wonderful. Simply by reading the device identifier in the
device's configuration space allows a device driver to attach to
hardware that it recognizes and make use of.=20

PCI evolved as a way to avoid the messy jumper settings one used to do
with old ISA cards. Thankfully that's been consigned to the junk bin.

PCIe is even better!
--=20
Tactical Nuclear Kittens

On 9/7/2012 2:43 PM, glen herrmannsfeldt wrote:
>
> But many have ROM on board for a specific processor.
>
> So, yes the host can read/write the registers but any onboard
> BIOS ROM won't help any.

The Alpha systems with PCI buses have a minimal x86 emulator in the 
firmware that will execute the BIOS ROM on some devices.  I do not know 
that it will work for unsupported devices.

In many cases the BIOS ROM is not used, as the Alpha firmware knows how 
to access or configure the device.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

A few years ago, Fred Kleinsorge (RIP) had taken the time to explain on
C.O.V some of the challenges of writing device drivers for devices that
had assumed the CPU would run basic 8086 instruction set.

Seems that some of the ROM contents of the device were to be executed by
the CPU. I would assume that such instructions included various IO
constructs to send data to and from the device which were native to the
x86 platform.

I would also assume that Fred and his gang would have to inercept those
during emulation in order to convert them to Alpha way of talkin to the
device.


In a utopian scenario where VMS were ported to x86,  VMS would obviously
have to use the x86 way of doing IO. But wouldn't that also mean
 that VMS engineering would have a much easier time of creating drivers
since they could "inspire" themselves from drivers coming from other x86
operating systems ?

Would this greatly simplify the writing of drivers for devices that had
alwasy assumed a x86 CPU was avaialble ? or would the difference be
fairly minimal because most of the work in a driver involves VMS
specific constructs ?

On 9/7/2012 10:40 PM, JF Mezei wrote:
> A few years ago, Fred Kleinsorge (RIP) had taken the time to explain on
> C.O.V some of the challenges of writing device drivers for devices that
> had assumed the CPU would run basic 8086 instruction set.
>
> Seems that some of the ROM contents of the device were to be executed by
> the CPU. I would assume that such instructions included various IO
> constructs to send data to and from the device which were native to the
> x86 platform.

The ROM on the devices is for two purposes.

1. Extend the 8088 Bios to allow it to boot a device that it does not 
know how to boot, and to allow DOS 6.22 and earlier to function.

Anything later than DOS 6.22 just used the ROM on disk controllers to 
load in the secondary boot loader into memory.  The secondary boot 
loader then loads in the actual drivers that the OS uses.

Non 8088 based operating systems ignore that ROM functionality, as their 
firmware already contains all the information needed to boot the device.

Those ROM routines are needed only to be backward compatible with DOS 6.22.

At no time when VMS or even (Linux after the initial boot), or even 
recent Microsoft Windows is running code from the ROM contents of the 
device.

Except for configuration utilities, the ROM on the devices is simply 
there to patch around the original 8088 boot device driver.  Something 
non-8088 platforms do not need done.

2. Run a basic configuration or diagnostic utility.  For this, the Alpha 
firmware has a minimal 8088 emulator so that it can be used to configure 
devices such as the Smart Array family.  I think that the Itanium EFI 
console also has such an emulator.

> In a utopian scenario where VMS were ported to x86,  VMS would obviously
> have to use the x86 way of doing IO. But wouldn't that also mean
>  that VMS engineering would have a much easier time of creating drivers
> since they could "inspire" themselves from drivers coming from other x86
> operating systems ?

As far as a mythical 80x86-64 port, basically all commercial operating 
systems for that platform now need to run in a Hypervisor.  And to run 
efficiently they need to have paravirtualized drivers.

Which means that actual device drivers are only needed for the 
hypervisor and not the operating system that the program sees.

This will probably happen to the VAX and Alpha emulators is that they 
will eventually move to paravirtualized drivers to get more performance.

Now VMS can stress the I/O hardware more than other operating systems, 
so it will need to have a hypervisor with very well developed and tested 
I/O drivers.

But the x86-64 based VMS only needs generic paravirtualized drivers, not 
drivers to support all the different widgets that are out there.  That 
is the hypervisor jobs.

And since a port of VMS to x86-64 needs to be able to run existing VMS 
binaries, it makes only sense not to actually recompile VMS to run on 
x86, but to actaully start out with an emulator, and then modify the 
emulator and VMS to also support running native x86-x64 binaries as sort 
of a thunking later.

This means that over time, you can rebuild libraries running on the 
emulator to actually be running x86-x64, and users could compile there 
applications.

Now some of the emulators appear to already be dynamically doing this 
based on run-time analysis.  I do not know of any of them that are 
deploying paravirtualized drivers, but that is just a matter of time.

This makes the most sense for a commercial port, as you can deploy VMS 
now on an emulator running on an x86_64 system and run your existing 
binaries.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

John E. Malmberg wrote:

> As far as a mythical 80x86-64 port, basically all commercial operating 
> systems for that platform now need to run in a Hypervisor.  And to run 
> efficiently they need to have paravirtualized drivers.

But if the config of a hypervisor allocates a disk array to VMS, doesn't
the hypervisor give VMS full access to the physical device ?

and if the hypervisor shares a physical disk array with multiple
insances, wouldn't each instance be given what it would see as its own
physical disk array running on some common hardware that the hypervisor
woudl assume every OS has drivers for ?

Or does the hypervisor require the OS have special hypervisor-specific
device drivers to deal with the virtualised hardware below it ?

Besides, if VMS is to be ported to x86, wouldn't it have to be able to
boot off real hardware before it can boot off virtualised ones & (walk
before it can run) ?  This would entail it would still require drivers
to access standard hardware such as SATA drives etc.

On 9/7/2012 11:52 PM, JF Mezei wrote:
> John E. Malmberg wrote:
>
>> As far as a mythical 80x86-64 port, basically all commercial operating
>> systems for that platform now need to run in a Hypervisor.  And to run
>> efficiently they need to have paravirtualized drivers.
>
> But if the config of a hypervisor allocates a disk array to VMS, doesn't
> the hypervisor give VMS full access to the physical device ?

The hypervisor gives the guest operating system access to either a 
physical or an emulated set of disk drives.  Only the hypervisor knows 
or cares which.

> and if the hypervisor shares a physical disk array with multiple
> insances, wouldn't each instance be given what it would see as its own
> physical disk array running on some common hardware that the hypervisor
> woudl assume every OS has drivers for ?

That is what the paravirtualized drivers are for.  Basically there is an 
API in which the paravirtualized driver on the guest OS really just 
passes control directly to the hypervisor driver with out doing much 
processing.

> Or does the hypervisor require the OS have special hypervisor-specific
> device drivers to deal with the virtualised hardware below it ?

Generally it is not required, but it is highly recommended if you want 
the best performance.  Otherwise it has to emulate some type of physical 
hardware that the guest OS has drivers for, which while it gets the 
guests OS running on it with the least amount of effort, but you do not 
get the best performance.

> Besides, if VMS is to be ported to x86, wouldn't it have to be able to
> boot off real hardware before it can boot off virtualised ones & (walk
> before it can run) ?  This would entail it would still require drivers
> to access standard hardware such as SATA drives etc.

No.  It only needs to have paravirtualized drivers for the best 
efficiency.  Only the hypervisor needs to care if the drives are SATA, 
SAS, or more likely the drives will be on a SAN, where the SAN 
controller is the only thing that cares what type of physical disks are 
there.

Currently for Server class x86_64 operating systems, they only need to 
run under a hypervisor.

There really is no advantage to not using a hypervisor if you have 
properly implemented the hypervisor and paravirtualized drivers.

So when porting a new operating system to x86, especially a server 
operating system, there is no reason to have it support anything other 
than the handful of  major hypervisors that are in use.

To not take advantage of a hypervisor in doing that port greatly 
increases the cost of doing and maintaining the port with out any real 
benefit to the person doing the port or their customers.

And one of the things that you can do with some hypervisor and guest 
os's is that you can freeze the guest OS on once physical instance of 
hypervisor hardware and unfreeze it running on a completely different 
physical instance of hypervisor hardware, with out any users of that 
guest OS realizing that it made the move.

And if you have good SAN replication, the two instances can even be in 
different cities.

So right now, this is something that you can do with most x86 based 
server operating system by running them under a Hypervisor and that 
includes VMS emulators running on those systems.

But you can not do that with VMS running on real hardware.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

> There really is no advantage to not using a hypervisor if you have 
> properly implemented the hypervisor and paravirtualized drivers.

If you have a mainframe class application, and need to have one instance
take up the whole server, are there still advantages of having a
hypervisor support just one instance ?

I can understand for a new OS which doesn't yet have all the drivers
eeded for the hardware. but once that OS has the required drivers, isn't
it far more efficient fr it to be on its own ?

remember that in the case of Windows, they need many instances because
the OS is designed for one application per instance. But for VMS this is
not the case.

On Sep 8, 6:53=A0am, "John E. Malmberg" <wb8...@qsl.network> wrote:
> On 9/7/2012 11:52 PM, JF Mezei wrote:
>
> > John E. Malmberg wrote:
>
> >> As far as a mythical 80x86-64 port, basically all commercial operating
> >> systems for that platform now need to run in a Hypervisor. =A0And to r=
un
> >> efficiently they need to have paravirtualized drivers.
>
> > But if the config of a hypervisor allocates a disk array to VMS, doesn'=
t
> > the hypervisor give VMS full access to the physical device ?
>
> The hypervisor gives the guest operating system access to either a
> physical or an emulated set of disk drives. =A0Only the hypervisor knows
> or cares which.
>
> > and if the hypervisor shares a physical disk array with multiple
> > insances, wouldn't each instance be given what it would see as its own
> > physical disk array running on some common hardware that the hypervisor
> > woudl assume every OS has drivers for ?
>
> That is what the paravirtualized drivers are for. =A0Basically there is a=
n
> API in which the paravirtualized driver on the guest OS really just
> passes control directly to the hypervisor driver with out doing much
> processing.
>
> > Or does the hypervisor require the OS have special hypervisor-specific
> > device drivers to deal with the virtualised hardware below it ?
>
> Generally it is not required, but it is highly recommended if you want
> the best performance. =A0Otherwise it has to emulate some type of physica=
l
> hardware that the guest OS has drivers for, which while it gets the
> guests OS running on it with the least amount of effort, but you do not
> get the best performance.
>
> > Besides, if VMS is to be ported to x86, wouldn't it have to be able to
> > boot off real hardware before it can boot off virtualised ones & (walk
> > before it can run) ? =A0This would entail it would still require driver=
s
> > to access standard hardware such as SATA drives etc.
>
> No. =A0It only needs to have paravirtualized drivers for the best
> efficiency. =A0Only the hypervisor needs to care if the drives are SATA,
> SAS, or more likely the drives will be on a SAN, where the SAN
> controller is the only thing that cares what type of physical disks are
> there.
>
> Currently for Server class x86_64 operating systems, they only need to
> run under a hypervisor.
>
> There really is no advantage to not using a hypervisor if you have
> properly implemented the hypervisor and paravirtualized drivers.
>
> So when porting a new operating system to x86, especially a server
> operating system, there is no reason to have it support anything other
> than the handful of =A0major hypervisors that are in use.
>
> To not take advantage of a hypervisor in doing that port greatly
> increases the cost of doing and maintaining the port with out any real
> benefit to the person doing the port or their customers.
>
> And one of the things that you can do with some hypervisor and guest
> os's is that you can freeze the guest OS on once physical instance of
> hypervisor hardware and unfreeze it running on a completely different
> physical instance of hypervisor hardware, with out any users of that
> guest OS realizing that it made the move.
>
> And if you have good SAN replication, the two instances can even be in
> different cities.
>
> So right now, this is something that you can do with most x86 based
> server operating system by running them under a Hypervisor and that
> includes VMS emulators running on those systems.
>
> But you can not do that with VMS running on real hardware.
>
> Regards,
> -John
> wb8...@qsl.network
> Personal Opinion Only

"There really is no advantage to not using a hypervisor if you have
properly implemented the hypervisor and paravirtualized drivers."


Cost? Not all HYPErvisors are free, and truly knowledgeable people in
the technology certainly aren't. Server hardware isn't expensive these
days. Saving money on power and cooling might be a win for
virtualisation, but ARM servers might soon be a win there too.
Application and OS software licence costs aren't usually affected
either way by virtualisation.

Performance? I've seen some real weird things with horribly slow disk
IO performance under ESX, but we had no experts to explain it (too
expensive).

Reliability? Who remembers when huge quantities of paid-for VMware
systems stopped on the same day because VMware's licence checking
broke? Have similar things happened again since? Either way it's
another extra layer where more things can go wrong. (Reliability .ne.
availability - there are some interesting things you can do with a
virtualised system that aren't so easy with a real OS running native).

Security? Again, another extra layer where vulnerabilities may exist
that wouldn't otherwise exist.

Yes I know I'm not presenting a balanced picture, plenty of people are
promoting HYPErvisors and they're unbalanced too.


Wrt BIOS stuff: the "BIOS emulation" on Alpha was specifically for VGA
BIOS emulation, was it not? Almost nothing else was necessary or
supported in that context in emulation terms. Once the OS is up there
was FX!32 for user mode Win32 code. There is some documentation on VGA
BIOS emulation in some of the Alpha Architecture Reference Manuals
(which reference the SRM console callbacks used for this purpose) but
I don't have my copy handy and don't have time or inclination to go
searching the dark corners of the Interweb.

On 2012-09-07 18:36:24 +0000, JF Mezei said:

> Stephen Hoffman wrote:
> 
>> Suggestion: try a computer architecture course, and not
>> comp.os.we-know-the-old-gear?
> 
> The computer architecture course I took at university dealt with And, Or
> Nand, Nor gates, interface with memory, but not IO. And at the time, the
> reference was the IBM 360/370 architecture.

So?  What colleges don't tell students: all of the tech you'll learn 
with - all of it - will be gone in five or ten years.    Take another 
class or three; the on-line Stanford courses I've attended, audited, 
whatever, are quite good, and many most of these online courses are 
free, as well as courses at coursera site or iTunes U, or at MIT and 
some other good schools.  Depending on your interests, there are other 
courses on other topics.  Khan Academy has a Python course 
<http://www.khanacademy.org/search?page_search_query=python>, for 
instance.

> The reason I ask is more historical. When DEC decided to use PCI with
> teh Alpha, how much work did it have to do to adapt a bus that was
> originally designed to live with x86 ?

I don't recall the engineering schedules.

At that time, DEC was doing a pile of custom semiconductors and ASICs, 
but various of the glue chips were off-the-shelf.  A few of the chips 
have been mentioned here over the years, not the least of which has 
been the Intel Saturn I/O 420-something-or-other chipset, and the Pyxis 
DECchip 21174, and you can search for details of the various systems.  
What you use can depend on the target market for the particular box.  
(Though the junk I/O stuff was generally junk on all the boxes; that 
nomenclature didn't come from anywhere strange.)

There was some work in the console to add support for executing the PCI 
boot and configuration ROMs; that shows up in various contexts.  (It's 
also why Intel was trying to encourage a byte code interpreter for ROMs 
in future boards, as part of the EFI and related work.)

Reworking the drivers was the usual hassle.  (There's a reason I keep 
referring to the "bag of drivers" here, too.  Writing and debugging and 
maintaining device drivers is a pain in the rump, and all hardware is a 
moving target.)

> Did DEC develop its own implementation of PCI that had the PCI specs on
> the bus itself, but totally different way to talk to the CPU ? Or was it
> able to use off-the-shelf chips that implement PCI and then tweaked
> firmware on the CPU side to talk to that chip ?

The DEC PCI was PCI.  I don't remember the revisions of the boxes, but 
PCI v2.0 was pretty common back then.  You can see this implementation 
compatibility by looking at the SCSI boards that were discussed 
recently by Rich Jordan; the two he listed were commodity boards that 
OpenVMS added driver support for.  Or the DEC PCI boards that could be 
used on x86 boxes.  (Again: bag-of-drivers.)

> There are now buses such as "Thunderbolt" when you can hook on various
> adaptors. So a  ethernet driver that is expecting to talk to an ethernet
> card ends up reaching the ethernet "card" via the thunderbolt, which
> implies a thunderbolt driver that gets in between the ethernet driver
> and the ethernet device.  Does the ethernet driver have to know it is
> talking to another driver instead of another device, or does the
> thunderbolt driver virtualise an ethernet card and the ethernet driver
> thinks it is talking to a card ?

Thunderbolt is a packetized and extended version of PCIe and DisplayPort.

Other packetized buses include SCSI, SAS, USB, ATAPI, Infiniband, 
Ethernet, etc...


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-08 03:40:12 +0000, JF Mezei said:

> A few years ago, Fred Kleinsorge (RIP) had taken the time to explain on
> C.O.V some of the challenges of writing device drivers for devices that
> had assumed the CPU would run basic 8086 instruction set.

The console contains a very limited x86 emulator for the boot ROMs, yes.

> Seems that some of the ROM contents of the device were to be executed by
> the CPU. I would assume that such instructions included various IO
> constructs to send data to and from the device which were native to the
> x86 platform.

Zero, zilch, nada to do with the reality of interacting with the board 
from a driver.

> I would also assume that Fred and his gang would have to inercept those
> during emulation in order to convert them to Alpha way of talkin to the
> device.

Nope.

> In a utopian scenario where VMS were ported to x86,  VMS would obviously
> have to use the x86 way of doing IO.

"Utopian" is much to optimistic for the possibility of porting VMS to 
x86-64, but then you're usually being boqu� about this porting stuff.  
(I believe that's the correct slang from your area for "stubborn" but 
if not, whoops; sorry.)  Without the industrial-scale source of revenue 
necessary for expending the effort, a port is a non-starter.

> But wouldn't that also mean
>  that VMS engineering would have a much easier time of creating drivers
> since they could "inspire" themselves from drivers coming from other x86
> operating systems ?

Folks do look at other drivers to see how some boards work, but that's 
got nothing to do with the host architecture - folks writing drivers 
necessarily know that - and everything to do with figuring out what 
sort of weirdness a particular board has implemented.  Some boards are 
documented. Some are not.  A number of the non-commodity graphics 
boards are only documented under NDA, if at all.

> Would this greatly simplify the writing of drivers for devices that had
> alwasy assumed a x86 CPU was avaialble ? or would the difference be
> fairly minimal because most of the work in a driver involves VMS
> specific constructs ?

The innards of VMS drivers are nothing like those of Linux drivers.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-08 04:52:29 +0000, JF Mezei said:

> John E. Malmberg wrote:
> 
>> As far as a mythical 80x86-64 port, basically all commercial operating
>> systems for that platform now need to run in a Hypervisor.  And to run
>> efficiently they need to have paravirtualized drivers.
> 
> But if the config of a hypervisor allocates a disk array to VMS, doesn't
> the hypervisor give VMS full access to the physical device ?

Physical drives?  How quaint.  A hypervisor might give the guest OS a 
range of blocks.  VMS could well believe that's a disk, but the 
hypervisor (or the storage controller) can do pretty much whatever it 
wants here.  That's why it's a hypervisor.  And in some cases, you can 
stack hypervisors, too.

> and if the hypervisor shares a physical disk array with multiple
> insances, wouldn't each instance be given what it would see as its own
> physical disk array running on some common hardware that the hypervisor
> woudl assume every OS has drivers for ?

That's how a hypervisor can work, yes.

> Or does the hypervisor require the OS have special hypervisor-specific
> device drivers to deal with the virtualised hardware below it ?

Some implementations do that (and IBM VM had virtual devices an eon 
ago), while some present the appearance of a controller that the OS 
supports, or both.

> Besides, if VMS is to be ported to x86,

By "if" you mean "after you become fabulously rich, and buy the OS and 
the engineering group from HP", right?

>  wouldn't it have to be able to
> boot off real hardware before it can boot off virtualised ones & (walk
> before it can run) ?  This would entail it would still require drivers
> to access standard hardware such as SATA drives etc.

Booting to a hypervisor would probably be easier, as a first step.  
Real hardware can be evil.  In this case, the hypervisor provides the 
bag of drivers and deals with the evil that is hardware, allowing the 
guest OS (under development, or otherwise) to avoid having to deal with 
that.

BTW: HP hasn't provided native-boot support for a full third of the 
supported current-generation Integrity servers; only hypervisor support.

Take a computer architecture course or two.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-08 06:20:26 +0000, JF Mezei said:

>> 
>> There really is no advantage to not using a hypervisor if you have
>> properly implemented the hypervisor and paravirtualized drivers.
> 
> If you have a mainframe class application, and need to have one instance
> take up the whole server, are there still advantages of having a
> hypervisor support just one instance ?

Yes.

Rolling in a test is easier.

Recovering can be easier.

> I can understand for a new OS which doesn't yet have all the drivers
> eeded for the hardware. but once that OS has the required drivers, isn't
> it far more efficient fr it to be on its own ?

The heavily-used paths (in an OS and in a VM and in a processor) are 
invariably optimized, so they're generally very fast.

If you really need performance, then your app might run directly on the VM.

Or directly on the iron.

It depends.

> remember that in the case of Windows, they need many instances because
> the OS is designed for one application per instance. But for VMS this is
> not the case.

Yes, it's quite commonly the case with VMS, too.  VMS systems can be 
and variously are tuned for specific applications, and there are 
settings for one application that will blow up another; one case I 
dealt with was due to the mailbox buffer sizes; one app needed those 
big, and another blew up with the bigger settings.  There are various 
good reasons for having one VMS app for instance, or the ability to 
roll in a clean VMS image.  In years past (with VMS), this sort of 
thing was done by having a pool of servers and rolling in disk images 
from InfoServer, but it's handy to have a VM around irrespective of the 
OS.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-08 10:15:53 +0000, John Wallace said:

> Security? Again, another extra layer where vulnerabilities may exist
> that wouldn't otherwise exist.

True in some ways, not so true in others; the virtual machine and the 
processor virtual machine assists have a much smaller surface to attack.

But breach the processor-level assists, however, and things get ugly 
for even the non-virtual machine environments; VM-enabled malware.

> 
> Yes I know I'm not presenting a balanced picture, plenty of people are
> promoting HYPErvisors and they're unbalanced too.

You can get in deep sneakers with any product and any technology.

> Wrt BIOS stuff: the "BIOS emulation" on Alpha was specifically for VGA
> BIOS emulation, was it not?

Various of the storage controllers used this, too.

> Almost nothing else was necessary or
> supported in that context in emulation terms. Once the OS is up there
> was FX!32 for user mode Win32 code.

The FX!32 stuff only worked with Microsoft Windows running on Alpha.  
What's in the SRM console is nowhere near that level of emulation.


-- 
Pure Personal Opinion | HoffmanLabs LLC

In article 
<a84ad877-1679-4607-b306-d7e1b6742c21@v22g2000vbu.googlegroups.com>,
 John Wallace <johnwallace4@gmail.com> wrote:

> Cost? Not all HYPErvisors are free, and truly knowledgeable people in
> the technology certainly aren't. Server hardware isn't expensive these
> days. Saving money on power and cooling might be a win for
> virtualisation, but ARM servers might soon be a win there too.
> Application and OS software licence costs aren't usually affected
> either way by virtualisation.
> 
> Performance? I've seen some real weird things with horribly slow disk
> IO performance under ESX, but we had no experts to explain it (too
> expensive).

Somewhere in the middle of my migration from Windows as virtual hosts 
for Linux clients to Linux hosting Windows clients I ran into some 
appalling I/O performance.  OK I am talking VirtualBox rather than 
VMware here...

When I did a 30 day trial of VMware workstation I had other performance 
problems from the swapping VMware does on each client's behalf.  Yes 
that feature or VMware does allow you to allocate more RAM to a set of 
clients than exists in total on the host system, but I couldn't find a 
way of switching it off even when running a single client with plenty of 
spare host memory.

> Reliability? Who remembers when huge quantities of paid-for VMware
> systems stopped on the same day because VMware's licence checking
> broke? Have similar things happened again since? Either way it's
> another extra layer where more things can go wrong. (Reliability .ne.
> availability - there are some interesting things you can do with a
> virtualised system that aren't so easy with a real OS running native).

A quick search for "VMware license problem" brings up a lot of hits.

Is this the issue you were thinking of?

http://www.pcmag.com/article2/0,2817,2328012,00.asp

> Security? Again, another extra layer where vulnerabilities may exist
> that wouldn't otherwise exist.
> 
> Yes I know I'm not presenting a balanced picture, plenty of people are
> promoting HYPErvisors and they're unbalanced too.

A dose of healthy scepticism is definitely called for when you hear some 
of the stuff spouted.

http://www.dilbert.com/strips/comic/2012-05-25/

-- 
Paul Sture

In article <k2fi6c$ogi$1@dont-email.me>,
 Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:

> On 2012-09-08 06:20:26 +0000, JF Mezei said:
> 
> >> 
> >> There really is no advantage to not using a hypervisor if you have
> >> properly implemented the hypervisor and paravirtualized drivers.
> > 
> > If you have a mainframe class application, and need to have one instance
> > take up the whole server, are there still advantages of having a
> > hypervisor support just one instance ?
> 
> Yes.
> 
> Rolling in a test is easier.
> 
> Recovering can be easier.

Backing up can be easier too, particularly where the host is running a 
backup solution which can do snapshots or can detect which blocks have 
changed and only back those up.

> > remember that in the case of Windows, they need many instances because
> > the OS is designed for one application per instance. But for VMS this is
> > not the case.
> 
> Yes, it's quite commonly the case with VMS, too.  VMS systems can be 
> and variously are tuned for specific applications, and there are 
> settings for one application that will blow up another; one case I 
> dealt with was due to the mailbox buffer sizes; one app needed those 
> big, and another blew up with the bigger settings.  There are various 
> good reasons for having one VMS app for instance, or the ability to 
> roll in a clean VMS image.  In years past (with VMS), this sort of 
> thing was done by having a pool of servers and rolling in disk images 
> from InfoServer, but it's handy to have a VM around irrespective of the 
> OS.

We had a couple of applications running on VMS which didn't happily 
coexist.  

One application which needed to process a *lot* of data looked for spare 
resources and simply grabbed them.  The team responsible for  the other 
application responded by upping priorities.  We put them on separate 
machines.

-- 
Paul Sture

On 2012-09-08 14:23:21 +0000, Paul Sture said:

> In article <k2fi6c$ogi$1@dont-email.me>,
>  Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> 
> 
>>> remember that in the case of Windows, they need many instances because
>>> the OS is designed for one application per instance. But for VMS this is
>>> not the case.
>> 
>> Yes, it's quite commonly the case with VMS, too.  VMS systems can be
>> and variously are tuned for specific applications, and there are
>> settings for one application that will blow up another; ... but it's 
>> handy to have a VM around irrespective of the
>> OS.
> 
> We had a couple of applications running on VMS which didn't happily
> coexist.
> 
> One application which needed to process a *lot* of data looked for spare
> resources and simply grabbed them.  The team responsible for  the other
> application responded by upping priorities.  We put them on separate
> machines.

Put another way, an operating system is a bag of drivers (and 
libraries) that an application can and does use to meet its needs.

The OS is increasingly treated as "just" an application dependency by 
the ISV and by IT.

With this is the trend toward fewer reasons to share disparent 
applications within an OS instance, too.

Though for some operating system platforms, software licensing can a 
consideration; that can increase the costs of stacking your 
applications, but then that's also how the vendors fund the work 
involved with the OS.



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 09/08/12 14:05, Paul Sture wrote:

>
> A dose of healthy scepticism is definitely called for when you hear some
> of the stuff spouted.
>
> http://www.dilbert.com/strips/comic/2012-05-25/
>

I'm sure it makes sense for some applications, but if it's all running on a
single hardware platform, you lose everything if that fails, or the vm 
machine
crashes. You can spread the risk a lot better by having separate 
hardware for
each major task, with separate os instance for each.

I know it's the current fashion and it probably saves power on large 
sites, but
for small shops, I see more complication and less reliability in terms 
of single
point of failure...

Regards,

Chris

In article <k2fmsa$jnn$1@dont-email.me>,
 Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:

> On 2012-09-08 14:23:21 +0000, Paul Sture said:
> 
> > In article <k2fi6c$ogi$1@dont-email.me>,
> >  Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> > 
> > 
> >>> remember that in the case of Windows, they need many instances because
> >>> the OS is designed for one application per instance. But for VMS this is
> >>> not the case.
> >> 
> >> Yes, it's quite commonly the case with VMS, too.  VMS systems can be
> >> and variously are tuned for specific applications, and there are
> >> settings for one application that will blow up another; ... but it's 
> >> handy to have a VM around irrespective of the
> >> OS.
> > 
> > We had a couple of applications running on VMS which didn't happily
> > coexist.
> > 
> > One application which needed to process a *lot* of data looked for spare
> > resources and simply grabbed them.  The team responsible for  the other
> > application responded by upping priorities.  We put them on separate
> > machines.

I have just remembered that when the Wildfire class of machines was 
first announced, I had the rest of my team in stitches when I dropped 
the comment "We have an app that can fill one of those" (referring to 
the first resource hungry app there).

> Put another way, an operating system is a bag of drivers (and 
> libraries) that an application can and does use to meet its needs.
> 
> The OS is increasingly treated as "just" an application dependency by 
> the ISV and by IT.

Agreed, and I find myself doing that nowadays.  Just yesterday, I 
discovered that application X got broken by Mountain Lion.  No sweat, 
let's install it in a Linux instance I already have.

"sudo apt-get install X" was all it took and that downloaded and 
installed all the dependencies in as well.

That is a very far cry from the time I built ImageMagick on OS X, where 
at almost every step I discovered more and more dependencies.

> With this is the trend toward fewer reasons to share disparent 
> applications within an OS instance, too.

Yep.  This is where virtual machines come in especially handy. Do I 
really need that test version of LAMP running full time?  No, I can fire 
it up when needed and simply save the machine state when I want the 
resources back.  When I restore that system to a running state, it picks 
up exactly where I left it, and (with the exception of a FreeBSD 
instance) comes back with the correct date and time etc.

There are distinct space / power / noise / heat advantages in my home 
office from running virtual machines, and it really doesn't take much 
imagination to see how that scales up to anything between a SME and 
large enterprise environment.

Oh, and back to that resource hungry app.  Most of the month it sat 
idle, but as soon as month end data came in from business branches it 
ran flat out for several days.  Security concerns would definitely be 
key in making a decision here, but that was a definite candidate for "on 
demand" computing.
 
> Though for some operating system platforms, software licensing can a 
> consideration; that can increase the costs of stacking your 
> applications, but then that's also how the vendors fund the work 
> involved with the OS.

It's no fun wading through much of the licensing stuff, but if you can 
get it right, the savings can make the effort well worth your while.

-- 
Paul Sture

On 09/08/12 13:24, Stephen Hoffman wrote:

>
> The innards of VMS drivers are nothing like those of Linux drivers.
>
>

So how are they different, other than different architecture and software
development methodology ?...

Regards,

Chris

On 2012-09-08 16:38:31 +0000, ChrisQ said:

> On 09/08/12 13:24, Stephen Hoffman wrote:
> 
>> 
>> The innards of VMS drivers are nothing like those of Linux drivers.
>> 
>> 
> 
> So how are they different, other than different architecture and 
> software development methodology ?...

Are the device drivers doing the same things?  Generally, yes.  But in 
different ways.

For an overview, skim 
<http://www.freesoftwaremagazine.com/articles/drivers_linux> (including 
a look at the included parallel port driver) or the 
<http://lwn.net/Kernel/LDD3/> book, then go look at the LRDRIVER.C 
parallel-port device driver source code (available in SYS$EXAMPLES:) 
and the Writing VMS Drivers in C book, and you'll start to get a feel 
for how different the device driver software architectures are.  (If 
you don't have access to the Writing VMS Drivers in C book, see the 
older driver manuals in the archived section of the documentation set.)



-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-08, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2012-09-07 18:36:24 +0000, JF Mezei said:
>> 
>> The computer architecture course I took at university dealt with And, Or
>> Nand, Nor gates, interface with memory, but not IO. And at the time, the
>> reference was the IBM 360/370 architecture.
>
> So?  What colleges don't tell students: all of the tech you'll learn 
> with - all of it - will be gone in five or ten years.    Take another 
> class or three; the on-line Stanford courses I've attended, audited, 
> whatever, are quite good, and many most of these online courses are 
> free, as well as courses at coursera site or iTunes U, or at MIT and 
> some other good schools.  Depending on your interests, there are other 
> courses on other topics.  Khan Academy has a Python course 
><http://www.khanacademy.org/search?page_search_query=python>, for 
> instance.
>

Given the types of questions JF is asking, I am getting the strong
feeling he doesn't have any feeling at all for the issues and general
concepts involved when writing code which interacts directly with the
hardware (ie: at bare metal level).

I wonder if it might be a good idea for him to buy one of the cheap
embedded boards to explore this world. Unfortunately, I have absolutely
no idea what to recommend for either hardware or development environment
for a beginner to this world.

Does anyone have any suggestions ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-09-08 22:40:54 +0000, Simon Clubley said:

> Given the types of questions JF is asking, I am getting the strong
> feeling he doesn't have any feeling at all for the issues and general
> concepts involved when writing code which interacts directly with the
> hardware (ie: at bare metal level).
> 
> I wonder if it might be a good idea for him to buy one of the cheap
> embedded boards to explore this world. Unfortunately, I have absolutely
> no idea what to recommend for either hardware or development environment
> for a beginner to this world.
> 
> Does anyone have any suggestions ?


On the cheap, and targeted for this sort of thing: 
<http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/>

In addition to the RaspberryPi, Arduino <http://www.arduino.cc> and 
Teensy <http://www.pjrc.com/teensy/> are popular choices, too.  
Seeeduino Stalker 
<http://www.seeedstudio.com/depot/seeeduino-stalker-atmega-328-p-600.html?cPath=132_133>, 
etc.

More advanced and more complex operating systems and often with x86 
hardware, dig around for discussions such as this one: 
<http://stackoverflow.com/questions/130065/how-should-i-go-about-doing-operating-system-development-for-the-x86-architectur>, 
etc.   And choices such as <http://wiki.osdev.org/>, 
<http://code.google.com/p/geekos/>, etc.

Or rewrite or rework one of the existing device drivers on VMS, using 
the HP example source code or rolling your own.  Or 
<https://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_HardwareDrivers/_index.html> 
and <http://osxbook.com>.  This if you want to start in the deep end of 
the pool, that is.


-- 
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote:

> Or rewrite or rework one of the existing device drivers on VMS, using 
> the HP example source code or rolling your own.  Or 
> <https://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_HardwareDrivers/_index.html> 
> and <http://osxbook.com>.  This if you want to start in the deep end of 
> the pool, that is.


or Get the world famous Stephen Hoffman to explain drivers in terms
simple enough that even JF can understand :-)

Would it be correct to state that drivers are not overly concerned about
the actual workings of the bus ?  It is the combination of hardware and
low level OS that associate a card on a bus to a driver, and the driver
then uses standard means (as defined by the computer's architecture) to
communicate with that card ?

On 9/8/2012 10:51 PM, JF Mezei wrote:
> Stephen Hoffman wrote:
>
>> Or rewrite or rework one of the existing device drivers on VMS, using
>> the HP example source code or rolling your own.  Or
>> <https://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_HardwareDrivers/_index.html>
>> and <http://osxbook.com>.  This if you want to start in the deep end of
>> the pool, that is.
>
> or Get the world famous Stephen Hoffman to explain drivers in terms
> simple enough that even JF can understand :-)
>
> Would it be correct to state that drivers are not overly concerned about
> the actual workings of the bus ?

On the Alpha there is a different set of routines that handle the 
hardware abstraction.  They look up the information on how the device is 
connected to the bus and present the relevant information to the driver.

It handles routing the appropriate interrupts to the driver and it 
presents the driver with the location of the status registers and other 
registers that it needs.

> It is the combination of hardware and low level OS that associate a
 > card on a bus to a driver, and the driver then uses standard means
 > (as defined by the computer's architecture) to
> communicate with that card ?

Yes.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

On Sep 7, 7:36=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Stephen Hoffman wrote:
> > Suggestion: try a computer architecture course, and not
> > comp.os.we-know-the-old-gear?
>
> The computer architecture course I took at university dealt with And, Or
> Nand, Nor gates, interface with memory, but not IO. And at the time, the
> reference was the IBM 360/370 architecture.
>
> The reason I ask is more historical. When DEC decided to use PCI with
> teh Alpha, how much work did it have to do to adapt a bus that was
> originally designed to live with x86 ?
>
> Did DEC develop its own implementation of PCI that had the PCI specs on
> the bus itself, but totally different way to talk to the CPU ? Or was it
> able to use off-the-shelf chips that implement PCI and then tweaked
> firmware on the CPU side to talk to that chip ?
>
> There are now buses such as "Thunderbolt" when you can hook on various
> adaptors. So a =A0ethernet driver that is expecting to talk to an etherne=
t
> card ends up reaching the ethernet "card" via the thunderbolt, which
> implies a thunderbolt driver that gets in between the ethernet driver
> and the ethernet device. =A0Does the ethernet driver have to know it is
> talking to another driver instead of another device, or does the
> thunderbolt driver virtualise an ethernet card and the ethernet driver
> thinks it is talking to a card ?

PCI was not initially designed specifically for x86.

There may have been Intel employees on the committee (aka SIG, iirc),
there may have been DEC employees on the committee, but it was
intended to be vendor independent. Currently "The Board of Directors
of the PCI-SIG has representatives from: Intel, Microsoft, IBM, AMD,
Sun Micro, HP, Broadcom, Agilent Technologies, and NVIDIA." (says
Wikipedia).

DEC's Alpha systems couldn't use x86 CPU-PCI chippery because the CPU
bus side of things on any Alpha worked differently than any x86 ever
did. The PCI side should have been compatible with the PCI spec in
both cases; that's what vendor-independent specifications are for.
Those who wanted to build a PCI peripheral without going into the
detail of the PCI spec and designing their own logic could buy ready
made interface chips like the PLX9060 (and similar) which, within its
limitations, was customisable and programmable. But not perfect and
not necessarily ultimate performance.

In practice once PCI became widespreads many chip+board vendors
designed their peripherals to "what worked" on the latest trendy x86
CPU->PCI chipset, without paying attention to what was in the fine
detail of the PCI spec.

Wearing my occasional Alpha support hat, I came across a handful of
peripheral suppliers wondering why their PCI cards+chips worked on x86
and misbehaved on Alpha (sometimes with the same source drivers, if we
were talking NT or Linux?).

The failing ones I remember had built to what they were used to and
worked on x86, rather than what's in the spec, so when Alpha comes
along with a CPU->PCI chipset they'd never seen before, one that used
parts of the spec these folks had never had reason to look at, and
exhibited legitimate behaviours they weren't expecting, there were
heads being scratched.

There was also at least one PLX misfeature corrected in a later
revision that caught out a couple of vendors I was working with. But
these things happen.

Only a few folk really needed to know this though.

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

(snip)
> Would it be correct to state that drivers are not overly concerned about
> the actual workings of the bus ?  It is the combination of hardware and
> low level OS that associate a card on a bus to a driver, and the driver
> then uses standard means (as defined by the computer's architecture) to
> communicate with that card ?

I suppose, but there are some interesting things that you do 
stil have to get right. For one, on a 16 or 32 bit bus, which
lines do you use for a byte wide port?

-- glen

glen herrmannsfeldt wrote:

> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> (snip)
>> Would it be correct to state that drivers are not overly concerned about
>> the actual workings of the bus ?  It is the combination of hardware and
>> low level OS that associate a card on a bus to a driver, and the driver
>> then uses standard means (as defined by the computer's architecture) to
>> communicate with that card ?
> 
> I suppose, but there are some interesting things that you do
> stil have to get right. For one, on a 16 or 32 bit bus, which
> lines do you use for a byte wide port?
> 

IMHO no, in my experience for a memory mapped I/O,
one only needs to know the "programming model" of the device, 
i.e. the memory layout (address offsets of the device registers) ,
the size of the registers, and the access modes (read,write, read+write).
This defines the possible instructions to access the device:
byte, word, longword, and eventually if only move/load/store is possible,
or RWM (read-modify-write) like bit-set,bit-clear,bit-test-and-clear,...
The software doesn't need to know of bus lines and such.

As long as CPU and bus are operating in the same endianess, also the bit 
positions within the items are of no concern to the programmer.
Only in cases where endianess between CPU and bus is reversed,
as is the case e.g. in Intel CPU (little endian) to VMEbus (big endian),
one needs to take care.
But in all implementations I had to deal with, the implementation of 
the bus bridge has an auto-byte-swap mode, so that to the software the
VME bus looks like a little endian memory.

 

-- 
 
 Joseph Huber   - http://www.huber-joseph.de

On Sat, 08 Sep 2012 16:30:30 +0000, ChrisQ wrote:

> On 09/08/12 14:05, Paul Sture wrote:
> 
> 
>> A dose of healthy scepticism is definitely called for when you hear
>> some of the stuff spouted.
>>
>> http://www.dilbert.com/strips/comic/2012-05-25/
>>
>>
> I'm sure it makes sense for some applications, but if it's all running
> on a single hardware platform, you lose everything if that fails, or the
> vm machine crashes. You can spread the risk a lot better by having
> separate hardware for each major task, with separate os instance for
> each.

Um yes.  A recent Fedora upgrade brought with it a new kernel and 
VirtualBox stopped working, taking out all my virtual clients :-)

Fortunately it left 2 previous versions of the kernel available in the 
boot menu, so I could select a compatible one at boot time.

Before anyone makes the comment that Fedora is "bleeding edge", yes it 
can be, and CentOS has been suggested as more suitable.  However CentOS 
doesn't support the NIC on this system - I found an article (which I 
cannot find now) stating that hardware build by the mainstream 
manufacturers in recent years was probably supported but if you had a 
self build system you might be out of luck.

> I know it's the current fashion and it probably saves power on large
> sites, but for small shops, I see more complication and less reliability
> in terms of single point of failure...

All your eggs in one basket maybe, but that brings us back to the single 
point of failure mainframe too.

-- 
Paul Sture

On Sep 8, 6:53=A0am, "John E. Malmberg" <wb8...@qsl.network> wrote:
> On 9/7/2012 11:52 PM, JF Mezei wrote:
>
> > John E. Malmberg wrote:
>
> >> As far as a mythical 80x86-64 port, basically all commercial operating
> >> systems for that platform now need to run in a Hypervisor. =A0And to r=
un
> >> efficiently they need to have paravirtualized drivers.
>
> > But if the config of a hypervisor allocates a disk array to VMS, doesn'=
t
> > the hypervisor give VMS full access to the physical device ?
>
> The hypervisor gives the guest operating system access to either a
> physical or an emulated set of disk drives. =A0Only the hypervisor knows
> or cares which.
>
> > and if the hypervisor shares a physical disk array with multiple
> > insances, wouldn't each instance be given what it would see as its own
> > physical disk array running on some common hardware that the hypervisor
> > woudl assume every OS has drivers for ?
>
> That is what the paravirtualized drivers are for. =A0Basically there is a=
n
> API in which the paravirtualized driver on the guest OS really just
> passes control directly to the hypervisor driver with out doing much
> processing.
>
> > Or does the hypervisor require the OS have special hypervisor-specific
> > device drivers to deal with the virtualised hardware below it ?
>
> Generally it is not required, but it is highly recommended if you want
> the best performance. =A0Otherwise it has to emulate some type of physica=
l
> hardware that the guest OS has drivers for, which while it gets the
> guests OS running on it with the least amount of effort, but you do not
> get the best performance.
>
> > Besides, if VMS is to be ported to x86, wouldn't it have to be able to
> > boot off real hardware before it can boot off virtualised ones & (walk
> > before it can run) ? =A0This would entail it would still require driver=
s
> > to access standard hardware such as SATA drives etc.
>
> No. =A0It only needs to have paravirtualized drivers for the best
> efficiency. =A0Only the hypervisor needs to care if the drives are SATA,
> SAS, or more likely the drives will be on a SAN, where the SAN
> controller is the only thing that cares what type of physical disks are
> there.
>
> Currently for Server class x86_64 operating systems, they only need to
> run under a hypervisor.
>
> There really is no advantage to not using a hypervisor if you have
> properly implemented the hypervisor and paravirtualized drivers.
>
> So when porting a new operating system to x86, especially a server
> operating system, there is no reason to have it support anything other
> than the handful of =A0major hypervisors that are in use.
>
> To not take advantage of a hypervisor in doing that port greatly
> increases the cost of doing and maintaining the port with out any real
> benefit to the person doing the port or their customers.
>
> And one of the things that you can do with some hypervisor and guest
> os's is that you can freeze the guest OS on once physical instance of
> hypervisor hardware and unfreeze it running on a completely different
> physical instance of hypervisor hardware, with out any users of that
> guest OS realizing that it made the move.
>
> And if you have good SAN replication, the two instances can even be in
> different cities.
>
> So right now, this is something that you can do with most x86 based
> server operating system by running them under a Hypervisor and that
> includes VMS emulators running on those systems.
>
> But you can not do that with VMS running on real hardware.
>
> Regards,
> -John
> wb8...@qsl.network
> Personal Opinion Only

"The hypervisor gives the guest operating system access to either a
physical or an emulated set of disk drives.  Only the hypervisor knows
or cares which. "

How does device-level error logging get done in these cases?

How might an OS under a hypervisor implement something like mount
verification for device error recovery and high availability and
predictive failure analysis?

Taking it a step further, what about a crash dump analysis toolset,
for post mortem debugging where "swap a card and wait till it happens
again" (or even change a software config and wait till it happens
again) isn't an option ? Are those things too out of fashion?

Feel free to extend the answer to the HyPervisor on IA64, not just
volume-market x86 ones.

[I'm guessing the answer is it generally doesn't get done because it
generally can't get done with the common hypervisor model, but even if
these things are no longer important in the hype-driven trendy IT
world, once upon a time some wise people used to think they were
important...]

On Sun, 2012-09-09 at 12:32 +0200, Paul Sture wrote:
> > I know it's the current fashion and it probably saves power on large
> > sites, but for small shops, I see more complication and less
> reliability in terms of single point of failure...
>=20
> All your eggs in one basket maybe, but that brings us back to the
> single point of failure mainframe too.=20

Recent advances in virtualisation means one can move VMs to other
machines transparently when things start going wrong.=20
--=20
Tactical Nuclear Kittens

On 09/09/12 10:32, Paul Sture wrote:

>
> All your eggs in one basket maybe, but that brings us back to the single
> point of failure mainframe too.
>

Yes, but mainframe companies like ibm have been doing virtualisation for
decades, afaik and they do seem to be a class act in more ways than one.
Who would you trust ?. It's fine if you have an old system that needs to
be emulated to run old software, but would I never base a whole business's
it strategy on it.

The current virtualisation fad seems to be going in exactly the opposite
direction to the old cluster idea, where several hardware instances provided
redundancy to cover single a instance of failure...

Regards,

Chris

On 09/09/12 11:46, Single Stage to Orbit wrote:

>
> Recent advances in virtualisation means one can move VMs to other
> machines transparently when things start going wrong.

That's fine if it works, but how about the cost of skilled and trained
staff to ensure that it actually works ?.

I guess the real beef is that it increases system complexity, isn't
so transparent in operation / debugging problems and opens up the
possibility of even more major failure, through the hardware itself
or human error...

Regards,

Chris

On 2012-09-09 03:51:49 +0000, JF Mezei said:

> Stephen Hoffman wrote:
> 
>> Or rewrite or rework one of the existing device drivers on VMS, using
>> the HP example source code or rolling your own.  Or
>> <https://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_HardwareDrivers/_index.html> 
>> 
>> and <http://osxbook.com>.  This if you want to start in the deep end of
>> the pool, that is.
> 
> 
> or Get the world famous Stephen Hoffman to explain drivers in terms
> simple enough that even JF can understand :-)

Here's a high-level overview of the VMS I/O stack 
<http://labs.hoffmanlabs.com/node/114>

You're not really going to gain a visceral understanding without 
tussling with semi-documented widgets and flaky firmware, 
unfortunately.  Until you get into some code and some driver debugging. 
 This is also why I can get cranky when somebody falls for the "just 
swap in j-random widget" foolishness, "because it's compatible".  
"Compatible" being the IT synonym for "different", of course.  This 
because if the device were truly "identical", it would not be 
advertised as being "compatible".  But I digress.

> Would it be correct to state that drivers are not overly concerned about
> the actual workings of the bus ?

Drivers usually only care about the rough equivalent of layer 2 and up 
<http://en.wikipedia.org/wiki/OSI_model>; about CSR addressing, and 
(where applicable) packets and higher-layer stuff.  Drivers might set 
the interrupt vector in the board (when it has a soft-loaded vector), 
but (in the case of VMS) the OS sets up the interrupt dispatcher and 
activates the interrupt service routine (handler) in the driver when 
something interesting happens with the widget.  And VMS itself doesn't 
necessarily know what the vector setting is (in various cases), and 
sets up based on assumptions - this is the case on the Q-bus.  
Something somewhere rang an interrupt, and (depending on the 
implementation details) the OS either logs it, ignores it, or passes 
the particular interrupt request along to something in the driver or 
the OS that was waiting for that interrupt vector.

As for your question...  Drivers are mostly concerned with the 
addressability (whether via PCI vendor and widget codes, or the Q-Bus 
configuration, or whatever) and then largely with the workings of the 
particular peripheral widget, and (for cases such as with SCSI) 
whatever widgets are on the bus behind it.  (Yes, hierarchies of buses 
are common.)

If a physical bus or bus adapter is malfunctioning, then the driver is 
scrod.  This sort of thing was more common back in the Q-bus and UNIBUS 
and earlier days, when an I/O or system bus could jam; it's why older 
VAX systems had UNJAM commands.  That's much less common, now.  (And 
I've encountered a malfunctioning UNIBUS Adapter (what was called a 
UBA, or specifically a DW780); that can cause some seriously weird 
problems.)


> It is the combination of hardware and
> low level OS that associate a card on a bus to a driver, and the driver
> then uses standard means (as defined by the computer's architecture) to
> communicate with that card ?

The bus(es) permit the peripheral card or the bus adapter to be 
addressable, and to transfer data.

There is no standard means to communicate with an arbitrary peripheral 
widget, and new and different ways are constantly arriving.  (Less 
often "new", more often "different".)

IDE/ATA, for instance, is all in the controller.  The widgets are dumb, 
and the IDE controller isn't very smart.  SCSI and IDE/ATAPI require 
communicating with a controller (via CSR) which then passes through to 
a remote peripheral using command packets and response packets.  (Look 
around for sys$qio or sys$qiow examples on OpenVMS that are using the 
IO$_DIAGNOSE function code; that can be a SCSI or ATAPI tool, passing 
along the command and response data blocks.)

Again, an OS provides a "bag of drivers" and "abstraction".  An 
operating system exists to abstract the differences between various 
widgets (which can be much larger than folks realize - VAX systems 
could be very different internally, from family to family), and to 
abstract all the flaky stuff that's going on at the hardware level.  
(And then there's the flaky stuff that happens within the hardware 
level, where error detection and correction catches and correct the 
processor or cache or memory or bus errors, before they get passed up 
to the higher layers; what HP is fond of calling RAS 
<http://labs.hoffmanlabs.com/node/95>)

-- 
Pure Personal Opinion | HoffmanLabs LLC

On 09/08/12 17:21, Stephen Hoffman wrote:

>
> Are the device drivers doing the same things? Generally, yes. But in
> different ways.
>
> For an overview, skim
> <http://www.freesoftwaremagazine.com/articles/drivers_linux> (including
> a look at the included parallel port driver) or the
> <http://lwn.net/Kernel/LDD3/> book, then go look at the LRDRIVER.C
> parallel-port device driver source code (available in SYS$EXAMPLES:) and
> the Writing VMS Drivers in C book, and you'll start to get a feel for
> how different the device driver software architectures are. (If you
> don't have access to the Writing VMS Drivers in C book, see the older
> driver manuals in the archived section of the documentation set.)
>

I would expect it to be very different, as the underlying os principles and
design is very different. Would expect the vms stuff to be far more 
disciplined,
though the linux crowd are more than just fussy these days.

Working in embedded space, I spend most of the time working at hardware 
level,
really enjoy the work and find it a constant source of fresh challenges 
in design
terms. Would recommend it to anyone with jaded appetite and too many 
years in
applications development.

J.F. was asking about this and how to start - Raspberry Pi might be one 
solution,
though apparently some of the hardware internals are not disclosed and 
the overall
view might be too high level. If you want to get your hands dirty with 
bits and
bytes at bare metal level, there are loads of different development kits 
from
cpu vendors, complete with C compiler, tools and a debug adapters ready to
plug in and go for < $100. ST Micro, TI Stellaris and others, for 
example. Forget
8051, Atmel AVR and PIC, for example, as they are last generation, 
limited / just
plain bad and not good examples of cpu architecture.

Try a google search for "arm cortex m3 development kits", for starters, 
there's a
lot to choose from...

Regards,

Chris

On 2012-09-09 08:37:53 +0000, John Wallace said:

> 
> Wearing my occasional Alpha support hat, I came across a handful of
> peripheral suppliers wondering why their PCI cards+chips worked on x86
> and misbehaved on Alpha (sometimes with the same source drivers, if we
> were talking NT or Linux?).
> 
> The failing ones I remember had built to what they were used to and
> worked on x86, rather than what's in the spec, so when Alpha comes
> along with a CPU->PCI chipset they'd never seen before, one that used
> parts of the spec these folks had never had reason to look at, and
> exhibited legitimate behaviours they weren't expecting, there were
> heads being scratched.

Ayup.  Engineering got to see that, too, and particularly when adding 
support for a new widget, and sometimes with a new revision of a widget.

The incompatibilities could involve parts of the spec that hadn't been 
implemented or hadn't been debugged (often because Windows didn't use 
it), or sometimes because VMS pounded on the peripheral much harder 
than had Windows and opened up a timing race.  Inconsistencies 
sometimes showed up with the controllers, and (because they're very 
complex) sometimes within the firmware in ATAPI and SCSI widgets.  When 
the weirdnesses cropped up, there were then discussions around whether 
to avoid the problem in the driver, or to fix it in the device 
firmware, or with some other approach.  And for completeness, there 
were also cases where the VMS driver was wrong, and manifested untoward 
behavior when a particular (unexpected, but arguably spec-compliant) 
behavior arose with a new widget.

And in the case of one widget connected to Microsoft Windows, 
Engineering got to see some devices that were tossing truly 
crazy-massive numbers of errors, and the widget clearly got shipped 
anyway.  The bus trace was.... interesting.   Amazingly, the end-user 
was likely unaware that the device was doing this badness; it was 
just... slow.  And it made everything else...slow.   Windows error 
recovery coped correctly with that error blizzard, and the device did 
perform its expected function...  Slowly.  VMS didn't end up using that 
widget.

> Only a few folk really needed to know this though.

Yep.  Definitely...

"Bag of drivers" and "abstraction"...

-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-09 11:10:48 +0000, John Wallace said:

> On Sep 8, 6:53�am, "John E. Malmberg" <wb8...@qsl.network> wrote:
>> On 9/7/2012 11:52 PM, JF Mezei wrote:
>> 
>>> John E. Malmberg wrote:
>> 
>>>> As far as a mythical 80x86-64 port, basically all commercial operating
>>>> systems for that platform now need to run in a Hypervisor. �And to run
>>>> efficiently they need to have paravirtualized drivers.
>> 
>>> But if the config of a hypervisor allocates a disk array to VMS, doesn't
>>> the hypervisor give VMS full access to the physical device ?
>> 
>> The hypervisor gives the guest operating system access to either a
>> physical or an emulated set of disk drives. �Only the hypervisor knows
>> or cares which.
>> 
>>> and if the hypervisor shares a physical disk array with multiple
>>> insances, wouldn't each instance be given what it would see as its own
>>> physical disk array running on some common hardware that the hypervisor
>>> woudl assume every OS has drivers for ?
>> 
>> That is what the paravirtualized drivers are for. �Basically there is an
>> API in which the paravirtualized driver on the guest OS really just
>> passes control directly to the hypervisor driver with out doing much
>> processing.
>> 
>>> Or does the hypervisor require the OS have special hypervisor-specific
>>> device drivers to deal with the virtualised hardware below it ?
>> 
>> Generally it is not required, but it is highly recommended if you want
>> the best performance. �Otherwise it has to emulate some type of physical
>> hardware that the guest OS has drivers for, which while it gets the
>> guests OS running on it with the least amount of effort, but you do not
>> get the best performance.
>> 
>>> Besides, if VMS is to be ported to x86, wouldn't it have to be able to
>>> boot off real hardware before it can boot off virtualised ones & (walk
>>> before it can run) ? �This would entail it would still require drivers
>>> to access standard hardware such as SATA drives etc.
>> 
>> No. �It only needs to have paravirtualized drivers for the best
>> efficiency. �Only the hypervisor needs to care if the drives are SATA,
>> SAS, or more likely the drives will be on a SAN, where the SAN
>> controller is the only thing that cares what type of physical disks are
>> there.
>> 
>> Currently for Server class x86_64 operating systems, they only need to
>> run under a hypervisor.
>> 
>> There really is no advantage to not using a hypervisor if you have
>> properly implemented the hypervisor and paravirtualized drivers.
>> 
>> So when porting a new operating system to x86, especially a server
>> operating system, there is no reason to have it support anything other
>> than the handful of �major hypervisors that are in use.
>> 
>> To not take advantage of a hypervisor in doing that port greatly
>> increases the cost of doing and maintaining the port with out any real
>> benefit to the person doing the port or their customers.
>> 
>> And one of the things that you can do with some hypervisor and guest
>> os's is that you can freeze the guest OS on once physical instance of
>> hypervisor hardware and unfreeze it running on a completely different
>> physical instance of hypervisor hardware, with out any users of that
>> guest OS realizing that it made the move.
>> 
>> And if you have good SAN replication, the two instances can even be in
>> different cities.
>> 
>> So right now, this is something that you can do with most x86 based
>> server operating system by running them under a Hypervisor and that
>> includes VMS emulators running on those systems.
>> 
>> But you can not do that with VMS running on real hardware.
>> 
>> Regards,
>> -John
>> wb8...@qsl.network
>> Personal Opinion Only
> 
> "The hypervisor gives the guest operating system access to either a
> physical or an emulated set of disk drives.  Only the hypervisor knows
> or cares which. "
> 
> How does device-level error logging get done in these cases?
> 
> How might an OS under a hypervisor implement something like mount
> verification for device error recovery and high availability and
> predictive failure analysis?
> 
> Taking it a step further, what about a crash dump analysis toolset,
> for post mortem debugging where "swap a card and wait till it happens
> again" (or even change a software config and wait till it happens
> again) isn't an option ? Are those things too out of fashion?
> 
> Feel free to extend the answer to the HyPervisor on IA64, not just
> volume-market x86 ones.
> 
> [I'm guessing the answer is it generally doesn't get done because it
> generally can't get done with the common hypervisor model, but even if
> these things are no longer important in the hype-driven trendy IT
> world, once upon a time some wise people used to think they were
> important...]

It's common in many environments to log to a central store using 
syslog, syslog-ng or analogous.  Unfortunately, VMS does not play well 
with others using syslog, et at.  HP uses their OSEM tool to aggregate 
and decode errors on a Windows box, here.  (These error tools 
<http://labs.hoffmanlabs.com/node/295> do seem to have short shelf 
lives.)

As for error logging, it varies.  If the VM has virtualized the device, 
then the VM logs the hardware errors.  Or not.  (The guest can log 
errors, too, but it's fairly unlikely that the VM would be emulating 
the generation of errors in a production build.)

For devices that are not virtualized, the guest is chatting directly 
with the widget, and (other than the mapping to the physical device 
that happens in the VM) the guest does with the device as it always has.

There are also cases where the VM has no clue about the hardware 
errors; where it's getting its disk storage from a controller, and the 
controller is presenting virtualized storage.  The only widget that 
knows about the errors is thus the storage controller, and then the VM 
(or the guest) gets involved if the controller doesn't log its own 
errors directly.

Error logging is another (large) quagmire, as usually only the vendor 
of the widget that's logging the error can decode the error, and the 
details of how the decoding is done is all over the map; there's no 
standard here for the details, beyond the generic "whoops" that can get 
passed up the stack.  Getting details off of an arbitrary SCSI device - 
such as how many blocks have been revectored - is usually within the 
vendor-specific details of the SCSI specs.

And when working with a VM, it's fastest to have the guest aware of the 
VM "downstairs", but dealing more or less directly with the hardware.  
(Trade-offs abound here, of course, and different goals have different 
designs.)

Again.... "Bag of drivers" and "abstraction"....


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-09 11:46:58 +0000, Single Stage to Orbit said:

> On Sun, 2012-09-09 at 12:32 +0200, Paul Sture wrote:
>>> I know it's the current fashion and it probably saves power on large
>>> sites, but for small shops, I see more complication and less
>> reliability in terms of single point of failure...
>> 
>> All your eggs in one basket maybe, but that brings us back to the
>> single point of failure mainframe too.
> Recent advances in virtualisation means one can move VMs to other
> machines transparently when things start going wrong.

IIRC, that was possible with IBM VM guests back in the 1980s...  You 
could stack the VMs with an IBM VM, too, which can be handy for testing 
and sometimes for deployments; guests ran on VM, and VM could run on 
VM, which ran on the iron.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-09 12:26:17 +0000, ChrisQ said:

> On 09/09/12 10:32, Paul Sture wrote:
> 
>> 
>> All your eggs in one basket maybe, but that brings us back to the single
>> point of failure mainframe too.
>> 
> 
> Yes, but mainframe companies like ibm have been doing virtualisation for
> decades, afaik and they do seem to be a class act in more ways than one.
> Who would you trust ?. It's fine if you have an old system that needs to
> be emulated to run old software, but would I never base a whole business's
> it strategy on it.

That depends on the scheme and on the particular business and on the 
requirements.

There are many different businesses and business models, and many 
different requirements.

The gonzo-scale always-up mainframe model works for some {businesses, 
requirments}, and definitely not for others.

> The current virtualisation fad seems to be going in exactly the opposite
> direction to the old cluster idea, where several hardware instances provided
> redundancy to cover single a instance of failure...

There are examples in all directions and dimensions.  VMS-style 
clustering split the difference between the single-instance stuff and 
brute-force uptime with cooperating hosts, and that's arguably where 
there's been the most innovation and the most varied solutions.  One 
current cluster analog can involve VM guests running instances with 
database-level replication of data; very close to what VMS-style 
clustering provides, able to sustain the loss of a guest or a server or 
a DC (depending on your configuration), and (with appropriate 
configurations) able to replicate and run entirely in memory.  With 
that, the disks are still around for the database transaction logs, but 
the whole design runs from memory.   And it's wicked fast.   Designs 
typical of a mainframe or of NSK go in an entirely different direction; 
brute-force uptime.  And IBM has its own single-system image clustering 
with Parallel Sysplex, and then there's the GDPS analog to the VMS DT 
clusters.

Different solutions with (wildly) different prices and different 
features and different exposures...



-- 
Pure Personal Opinion | HoffmanLabs LLC

In article <dr7uh9-n7c.ln1@news1.chingola.ch>,
	Paul Sture <nospam@sture.ch> writes:
> On Sat, 08 Sep 2012 16:30:30 +0000, ChrisQ wrote:
> 
>> On 09/08/12 14:05, Paul Sture wrote:
>> 
>> 
>>> A dose of healthy scepticism is definitely called for when you hear
>>> some of the stuff spouted.
>>>
>>> http://www.dilbert.com/strips/comic/2012-05-25/
>>>
>>>
>> I'm sure it makes sense for some applications, but if it's all running
>> on a single hardware platform, you lose everything if that fails, or the
>> vm machine crashes. You can spread the risk a lot better by having
>> separate hardware for each major task, with separate os instance for
>> each.
> 
> Um yes.  A recent Fedora upgrade brought with it a new kernel and 
> VirtualBox stopped working, taking out all my virtual clients :-)
> 
> Fortunately it left 2 previous versions of the kernel available in the 
> boot menu, so I could select a compatible one at boot time.
> 
> Before anyone makes the comment that Fedora is "bleeding edge", yes it 
> can be, and CentOS has been suggested as more suitable.  However CentOS 
> doesn't support the NIC on this system - I found an article (which I 
> cannot find now) stating that hardware build by the mainstream 
> manufacturers in recent years was probably supported but if you had a 
> self build system you might be out of luck.
> 
>> I know it's the current fashion and it probably saves power on large
>> sites, but for small shops, I see more complication and less reliability
>> in terms of single point of failure...
> 
> All your eggs in one basket maybe, but that brings us back to the single 
> point of failure mainframe too.

Has the term "COOP" faded from memory?  I remember making monthly
trips to our COOP Site back in my Univac Mainframe days to make sure
everything worked in case we actually needed it.

Of course, in the 8 years I worked there I never saw a noticable outage.
Having an onsite tech rep probably went a long way, too.  More proactive
than reactive.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

On Sep 9, 1:58=A0pm, ChrisQ <m...@devnull.com> wrote:
> On 09/08/12 17:21, Stephen Hoffman wrote:
>
>
>
> > Are the device drivers doing the same things? Generally, yes. But in
> > different ways.
>
> > For an overview, skim
> > <http://www.freesoftwaremagazine.com/articles/drivers_linux> (including
> > a look at the included parallel port driver) or the
> > <http://lwn.net/Kernel/LDD3/> book, then go look at the LRDRIVER.C
> > parallel-port device driver source code (available in SYS$EXAMPLES:) an=
d
> > the Writing VMS Drivers in C book, and you'll start to get a feel for
> > how different the device driver software architectures are. (If you
> > don't have access to the Writing VMS Drivers in C book, see the older
> > driver manuals in the archived section of the documentation set.)
>
> I would expect it to be very different, as the underlying os principles a=
nd
> design is very different. Would expect the vms stuff to be far more
> disciplined,
> though the linux crowd are more than just fussy these days.
>
> Working in embedded space, I spend most of the time working at hardware
> level,
> really enjoy the work and find it a constant source of fresh challenges
> in design
> terms. Would recommend it to anyone with jaded appetite and too many
> years in
> applications development.
>
> J.F. was asking about this and how to start - Raspberry Pi might be one
> solution,
> though apparently some of the hardware internals are not disclosed and
> the overall
> view might be too high level. If you want to get your hands dirty with
> bits and
> bytes at bare metal level, there are loads of different development kits
> from
> cpu vendors, complete with C compiler, tools and a debug adapters ready t=
o
> plug in and go for < $100. ST Micro, TI Stellaris and others, for
> example. Forget
> 8051, Atmel AVR and PIC, for example, as they are last generation,
> limited / just
> plain bad and not good examples of cpu architecture.
>
> Try a google search for "arm cortex m3 development kits", for starters,
> there's a
> lot to choose from...
>
> Regards,
>
> Chris

I don't know the internals of RasPi much but afaik the non-disclosed
bits relate to NDA/licenced graphics and other non-beginner stuff. If
I had time, RasPi might well be where I'd start.

Or I'd carry on where I left off, on an old PC with an x86 Linux, but
you never know *quite* what you're getting with an x86 PC and a random
Linux, either with hardware or software.

RasPi has lots of people with almost exactly the same hardware and
software config, which is handy for a beginner looking to learn.

The value of "lots of identical configurations" vs lots of zero cost
but not quite identical things is something which seems to be
overlooked or undervalued by many of the RasPi unbelievers. I guess
they've never looked at anything resembling a volume rollout (or even
a class-size rollout).

Anyway, once things get into kernel mode, device drivers etc, LDD3 is
great but last time I looked it was somewhat dated, don't know whether
it would match RasPi's OS, or whether the differences are sufficiently
well hidden for most purposes (I was tinkering with serial drivers
which may be about as bad as it gets). Fortunately there are plenty of
other resources for most things (serial drivers? Don't go there).
Finding the right resource for your hardware and software can be
interesting. Again, there is value in consistency, hence RasPi as
first choice (based on potential audience size).

Pionerring (sic) can be fun, but is not necessarily quick or
productive. Going where others have been before is usually more
productive.


UserMode Application <-> OS User APIs <-> Kernel <-> Driver+Kernel
APIs <-> [kernel mode code] <-> hardware <-> world.

At that level of complexity it's the same with VMS and Linux. Beyond
that it gets more interesting.

ChrisQ wrote:
> On 09/09/12 11:46, Single Stage to Orbit wrote:
> 
>>
>> Recent advances in virtualisation means one can move VMs to other
>> machines transparently when things start going wrong.
> 
> That's fine if it works, but how about the cost of skilled and trained
> staff to ensure that it actually works ?.
> 
> I guess the real beef is that it increases system complexity, isn't
> so transparent in operation / debugging problems and opens up the
> possibility of even more major failure, through the hardware itself
> or human error...
> 
> Regards,
> 
> Chris
> 

Isn't that why some of us like the VMS cluster capability?  A piece of 
hardware can fail, but the "system" continues to provide service.

But I don't think that a VMS cluster totally addresses the complexity, 
or the cost of skilled and trained people, or even human error.

I've been reading this thread, and now my brain (what's left of it) is 
hurting again.  I'm going to have to research "hypervisor" and some of 
the other terms.

I'm not sure just what the connection is between VM which supports 
multiple guest OS, and the stuff John is hurting my brain with that 
perhaps supports a guest OS that would not by itself run on specific 
hardware.  While it seems that similar techniques may be used to 
implement such, I'm thinking that that doesn't mean that both (VM and 
whatever) imply that all systems should be running multiple instances of 
an OS, or different OS.

While VM may be useful in some cases, I'm not very pleased with the 
concept.  We had been moving toward multiple CPUs and systems for 
redundancy, and VM seems the opposite of that, all your eggs in one 
basket.  Perhaps in a non-production environment the ability to run 
multiple and different OS would be useful.  Guess it depends upon the 
requirements.

On 2012-09-09 17:17:34 +0000, David Froble said:

> ChrisQ wrote:
>> On 09/09/12 11:46, Single Stage to Orbit wrote:
>> 
>>> 
>>> Recent advances in virtualisation means one can move VMs to other
>>> machines transparently when things start going wrong.
>> 
>> That's fine if it works, but how about the cost of skilled and trained
>> staff to ensure that it actually works ?.
>> 
>> I guess the real beef is that it increases system complexity, isn't
>> so transparent in operation / debugging problems and opens up the
>> possibility of even more major failure, through the hardware itself
>> or human error...
> 
> Isn't that why some of us like the VMS cluster capability?  A piece of 
> hardware can fail, but the "system" continues to provide service.

In your framework, a virtual machine guest would provide an easy way to 
roll in or roll out a cluster member in the same box, or rolling an 
instance in and out in an OpenVMS Galaxy.  OpenVMS has long had 
something similar both with Galaxy and the general ability to 
autoconfigure on boot, but this capability hasn't been as common on 
other platforms.  And VMS never really got to the ability to 
"freeze-dry" itself, though the Fast Boot stuff was close.

> But I don't think that a VMS cluster totally addresses the complexity, 
> or the cost of skilled and trained people, or even human error.

Nope; it doesn't.

IT is bifurcating.  The end-user stuff is getting easier and more 
capable, but the server-end back-end stuff (cloud services, VMs, co-lo, 
whatever) is still a quagmire.

> I've been reading this thread, and now my brain (what's left of it) is 
> hurting again.  I'm going to have to research "hypervisor" and some of 
> the other terms.

In OpenVMS, HP-VM or HP-IVM is the hypervisor layer with OpenVMS I64 on 
Integrity servers with specific Itanium processors 
<http://labs.hoffmanlabs.com/node/1440>

> I'm not sure just what the connection is between VM which supports 
> multiple guest OS, and the stuff John is hurting my brain with that 
> perhaps supports a guest OS that would not by itself run on specific 
> hardware.

Virtual Machines and Hypervisors are two terms for the same thing.

> While it seems that similar techniques may be used to implement such, 
> I'm thinking that that doesn't mean that both (VM and whatever) imply 
> that all systems should be running multiple instances of an OS, or 
> different OS.

That's quite possible.  It's also possible to use a virtual machine to 
test a virtual machine (in some cases), too.  If you have guests that 
aren't using the system heavily, a virtual machine can allow you to 
share the box - this is analogous to how an OpenVMS Galaxy can allow 
some sharing.

An OpenVMS Galaxy does not have a virtual machine monitor/hypervisor, 
OpenVMS and the SRM cooperated to divvy up the hardware resources.

> While VM may be useful in some cases, I'm not very pleased with the 
> concept.  We had been moving toward multiple CPUs and systems for 
> redundancy, and VM seems the opposite of that, all your eggs in one 
> basket.  Perhaps in a non-production environment the ability to run 
> multiple and different OS would be useful.  Guess it depends upon the 
> requirements.

Nothing prevents you from clustering across multiple physical boxes, 
with some or all of the cluster members running as virtual machines and 
some as traditionally-bootstrapped boxes.  Mix in an OpenVMS Galaxy and 
a VAX and a VAX emulation and and a half-dozen OpenVMS I64 guests in an 
Integrity HP-VM, and you're off to the complexity races...


-- 
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman wrote:
> On 2012-09-09 17:17:34 +0000, David Froble said:
> 
>> ChrisQ wrote:
>>> On 09/09/12 11:46, Single Stage to Orbit wrote:
>>>
>>>>
>>>> Recent advances in virtualisation means one can move VMs to other
>>>> machines transparently when things start going wrong.
>>>
>>> That's fine if it works, but how about the cost of skilled and trained
>>> staff to ensure that it actually works ?.
>>>
>>> I guess the real beef is that it increases system complexity, isn't
>>> so transparent in operation / debugging problems and opens up the
>>> possibility of even more major failure, through the hardware itself
>>> or human error...
>>
>> Isn't that why some of us like the VMS cluster capability?  A piece of 
>> hardware can fail, but the "system" continues to provide service.
> 
> In your framework, a virtual machine guest would provide an easy way to 
> roll in or roll out a cluster member in the same box, or rolling an 
> instance in and out in an OpenVMS Galaxy.  OpenVMS has long had 
> something similar both with Galaxy and the general ability to 
> autoconfigure on boot, but this capability hasn't been as common on 
> other platforms.  And VMS never really got to the ability to 
> "freeze-dry" itself, though the Fast Boot stuff was close.
> 
>> But I don't think that a VMS cluster totally addresses the complexity, 
>> or the cost of skilled and trained people, or even human error.
> 
> Nope; it doesn't.
> 
> IT is bifurcating.  The end-user stuff is getting easier and more 
> capable, but the server-end back-end stuff (cloud services, VMs, co-lo, 
> whatever) is still a quagmire.
> 
>> I've been reading this thread, and now my brain (what's left of it) is 
>> hurting again.  I'm going to have to research "hypervisor" and some of 
>> the other terms.
> 
> In OpenVMS, HP-VM or HP-IVM is the hypervisor layer with OpenVMS I64 on 
> Integrity servers with specific Itanium processors 
> <http://labs.hoffmanlabs.com/node/1440>
> 
>> I'm not sure just what the connection is between VM which supports 
>> multiple guest OS, and the stuff John is hurting my brain with that 
>> perhaps supports a guest OS that would not by itself run on specific 
>> hardware.
> 
> Virtual Machines and Hypervisors are two terms for the same thing.
> 
>> While it seems that similar techniques may be used to implement such, 
>> I'm thinking that that doesn't mean that both (VM and whatever) imply 
>> that all systems should be running multiple instances of an OS, or 
>> different OS.
> 
> That's quite possible.  It's also possible to use a virtual machine to 
> test a virtual machine (in some cases), too.  If you have guests that 
> aren't using the system heavily, a virtual machine can allow you to 
> share the box - this is analogous to how an OpenVMS Galaxy can allow 
> some sharing.
> 
> An OpenVMS Galaxy does not have a virtual machine monitor/hypervisor, 
> OpenVMS and the SRM cooperated to divvy up the hardware resources.
> 
>> While VM may be useful in some cases, I'm not very pleased with the 
>> concept.  We had been moving toward multiple CPUs and systems for 
>> redundancy, and VM seems the opposite of that, all your eggs in one 
>> basket.  Perhaps in a non-production environment the ability to run 
>> multiple and different OS would be useful.  Guess it depends upon the 
>> requirements.
> 
> Nothing prevents you from clustering across multiple physical boxes, 
> with some or all of the cluster members running as virtual machines and 
> some as traditionally-bootstrapped boxes.  Mix in an OpenVMS Galaxy and 
> a VAX and a VAX emulation and and a half-dozen OpenVMS I64 guests in an 
> Integrity HP-VM, and you're off to the complexity races...
> 
> 

After some research, at least I now understand what's being discussed. 
At least I think I do.  What it's done is send me off on what I think is 
a tangent, at least from how VM seems to be normally used.

As some of you know, I "don't get out much", and haven't looked around 
at such things as Unix, Linux, and some others.  So my preconceptions 
are about how well I like VMS and all the things in weendoze that 
irritate me.

This discussion has caused me to ask, why should an OS have to deal with 
devices?  An OS like VMS does vastly different things, one part dealing 
with devices, another memory (if it's not considered a device), and 
there is scheduling jobs, and providing other services.

So I'm wondering about an environment where there is (Ok, I'll use 
Microsoft's term) something like a hardware abstraction layer that 
interacts with the hardware and provides services to an OS.  Don't 
everyone yell at me "hey dummy, that's been going on for a long time". 
 From my reading, IBM was doing similar things 50 years ago.  Anyway, 
the thought was, if there was a standard for such an interface, then all 
OSs could be written to use the standard services.

As an example, would VMS have had such a hard time with video adapters, 
if the underlying "hardware handler" was handling the video adapters, 
not the OS?  For disk storage, why should an OS need to concern itself 
with anything lower level than "files"?

After reading a bit, and thinking a bit, I'm warming up to what John's 
suggesting.  However, the concurrent discussion about PCI devices and 
how well various ones conformed to the PCI standard, reality seems to 
make such ideas less than practical.

David Froble wrote:

> As an example, would VMS have had such a hard time with video adapters, 
> if the underlying "hardware handler" was handling the video adapters, 
> not the OS?  For disk storage, why should an OS need to concern itself 
> with anything lower level than "files"?

At the end of the day you still end up having to write a driver for
every device. Whether that driver resides in the OS or in the VM, it is
still there.

The more you shift from the OS to the VM, the more the VM becomes an
operating system which ends up supporting multiple applications, just
like real operating systems have been able to do for eons.

Ironically, IBM's VM back in the 70 and early 1980s supported
interactive use. When you logged in, you got your own virtual machine
(CMS) with your own devices and shared access to common devices.  Many
IBM shops used VM/CMS to provide interactive use for programmers while
DOS/VSE ran batch jobs on the same physical box.

While Windows has never had a shortage of drivers, Linux has. Commercial
VM engines basically provide drivers for hardware which Linux may not
have and pesent to Linux a device Linux knows about. It is a way to fill
gaps that the "community" doesn't fill on Linux.

Politically, it allows each department to have their own instance they
can manage as they wish without impacting others. So they can have
departmental systems without the costs of building a computer room (or
cannabalising an office to house the server).

Commercially, it allows data centres to host customers on farms of x86
servers with many customers per server, each running their instance of
whatever they want (Linux, Windows etc).

There are valid uses for virtualised environents, And there are "hyped"
uses for them.

On 2012-09-08, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2012-09-08 22:40:54 +0000, Simon Clubley said:
>
>> Given the types of questions JF is asking, I am getting the strong
>> feeling he doesn't have any feeling at all for the issues and general
>> concepts involved when writing code which interacts directly with the
>> hardware (ie: at bare metal level).
>> 
>> I wonder if it might be a good idea for him to buy one of the cheap
>> embedded boards to explore this world. Unfortunately, I have absolutely
>> no idea what to recommend for either hardware or development environment
>> for a beginner to this world.
>> 
>> Does anyone have any suggestions ?
>
>
> On the cheap, and targeted for this sort of thing: 
><http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/>
>
> In addition to the RaspberryPi, Arduino <http://www.arduino.cc> and 
> Teensy <http://www.pjrc.com/teensy/> are popular choices, too.  
> Seeeduino Stalker 
><http://www.seeedstudio.com/depot/seeeduino-stalker-atmega-328-p-600.html?cPath=132_133>, 
> etc.
>

These are good suggestions, and probably have enough beginning level
users that one user is likely to able be easily help another with the
basic issues.

> More advanced and more complex operating systems and often with x86 
> hardware, dig around for discussions such as this one: 
><http://stackoverflow.com/questions/130065/how-should-i-go-about-doing-operating-system-development-for-the-x86-architectur>, 
> etc.   And choices such as <http://wiki.osdev.org/>, 
><http://code.google.com/p/geekos/>, etc.
>
> Or rewrite or rework one of the existing device drivers on VMS, using 
> the HP example source code or rolling your own.  Or 
><https://developer.apple.com/library/mac/#referencelibrary/GettingStarted/GS_HardwareDrivers/_index.html> 
> and <http://osxbook.com>.  This if you want to start in the deep end of 
> the pool, that is.
>

$ set response/mode=good_natured

I said _beginner_ level introductions. :-)

Seriously however, I recognise that what can seem simple or a nice little
project to those of us who have been doing this for a while, can seem
to be a overwhelming mass of detail for a newcomer. I was reluctant to
make suggestions because I really didn't have a feel for what a good
first embedded board/development environment would be these days.

I think your first few suggestions are good ones, although I would leave
the Raspberry Pi until later if the goal was bare metal programming, and
I would also possibly add the Cortex-M3 evaluation boards to the list.
I wonder what the suggested introductory development environment is these
days. Is it still Eclipse or has something else come along ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2012-09-09 19:20:02 +0000, David Froble said:
> 
> After some research, at least I now understand what's being discussed. 
> At least I think I do.  What it's done is send me off on what I think 
> is a tangent, at least from how VM seems to be normally used.
> 
> As some of you know, I "don't get out much", and haven't looked around 
> at such things as Unix, Linux, and some others.  So my preconceptions 
> are about how well I like VMS and all the things in weendoze that 
> irritate me.
> 
> This discussion has caused me to ask, why should an OS have to deal 
> with devices?  An OS like VMS does vastly different things, one part 
> dealing with devices, another memory (if it's not considered a device), 
> and there is scheduling jobs, and providing other services.
> 
> So I'm wondering about an environment where there is (Ok, I'll use 
> Microsoft's term) something like a hardware abstraction layer that 
> interacts with the hardware and provides services to an OS.  Don't 
> everyone yell at me "hey dummy, that's been going on for a long time".  
> From my reading, IBM was doing similar things 50 years ago.  Anyway, 
> the thought was, if there was a standard for such an interface, then 
> all OSs could be written to use the standard services.

There hasn't been a standard for devices, unfortunately.  Beyond 
Windows, obviously.

As for porting the OS around, VMS doesn't have a defined abstraction layer.

Though the operating system has gained much in portability since its 
VAX days, certainly.

> As an example, would VMS have had such a hard time with video adapters, 
> if the underlying "hardware handler" was handling the video adapters, 
> not the OS?

The VGA interface has been consistent, but there's not been much 
consistency since then.

> For disk storage, why should an OS need to concern itself with anything 
> lower level than "files"?

That's a common pattern on newer platforms; where directories aren't at 
the forefront of the storage.

But as for why that can be a problem, there's I/O caching and I/O and 
memory prefetching.   That's always a trade-off; whether that's closest 
to the application, in the OS I/O system, the I/O controller and the 
outboard storage controller.  VMS and VMS apps use all these.  Push 
that down into the VM, and your cache efficiency can suffer.  Push it 
up into the application, and you can chew through a whole lot of 
memory, and the overhead of moving all that around.  And then there's 
the "fun" of keeping all the caches consistent.

There's a compromise between going directly for better performance, and 
going through the intermediate virtualized devices.

Intel tried to deploy a byte code interpreter here, which was a very 
useful idea that never got traction.  In that scheme, the board shipped 
with a ROM-based tools and a driver.  That would avoid the need for 
boot drivers and (for cases where performance wasn't critical) with 
general device access.

In the case of VMS, boot drivers are limited-function drivers that are 
used to get VMS going on a particular set of core devices, and once 
things are underway, VMS switches to the main device drivers.


-- 
Pure Personal Opinion | HoffmanLabs LLC

More courses...

Hardware-Software Interface:
https://www.coursera.org/course/hardware

Computer Architecture:
https://www.coursera.org/course/comparch

On Sep 9, 8:52=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> David Froble wrote:
> > As an example, would VMS have had such a hard time with video adapters,
> > if the underlying "hardware handler" was handling the video adapters,
> > not the OS? =A0For disk storage, why should an OS need to concern itsel=
f
> > with anything lower level than "files"?
>
> At the end of the day you still end up having to write a driver for
> every device. Whether that driver resides in the OS or in the VM, it is
> still there.
>
> The more you shift from the OS to the VM, the more the VM becomes an
> operating system which ends up supporting multiple applications, just
> like real operating systems have been able to do for eons.
>
> Ironically, IBM's VM back in the 70 and early 1980s supported
> interactive use. When you logged in, you got your own virtual machine
> (CMS) with your own devices and shared access to common devices. =A0Many
> IBM shops used VM/CMS to provide interactive use for programmers while
> DOS/VSE ran batch jobs on the same physical box.
>
> While Windows has never had a shortage of drivers, Linux has. Commercial
> VM engines basically provide drivers for hardware which Linux may not
> have and pesent to Linux a device Linux knows about. It is a way to fill
> gaps that the "community" doesn't fill on Linux.
>
> Politically, it allows each department to have their own instance they
> can manage as they wish without impacting others. So they can have
> departmental systems without the costs of building a computer room (or
> cannabalising an office to house the server).
>
> Commercially, it allows data centres to host customers on farms of x86
> servers with many customers per server, each running their instance of
> whatever they want (Linux, Windows etc).
>
> There are valid uses for virtualised environents, And there are "hyped"
> uses for them.

"The more you shift from the OS to the VM, the more the VM becomes an
operating system which ends up supporting multiple applications"

Kerching!

JF gets it! (as does Dave Froble, more below on that).

The hypervisor has to do resource allocation and scheduling, some kind
of security, loads of stuff a classical OS never did (system snapshot
and mobility across dissimilar hardware), system error handling and
management, provide a management interface to the administrators, and
more. How is it going to do that?

The hypervisor still needs lots of device drivers, just like JF says.
VMware (ESX at least) started life by using pieces from Linux (at boot
time and arguably later), but that was a few years ago, I don't know
where they are know.

What is there that the hypervisor *doesn't* have to do that a real OS
has to do? As far as I can see, it doesn't have to provide an
environment to run user mode Win32 (or Linux, or DOS, or...) code. And
arguably that is the *least difficult* bit of this picture. Anything
else it doesn't have to do?

How does it work that a hypervisor of this complexity has enhanced
security by providing a smaller "attack surface" than a real OS ? DOS
had quite a small attack surface too, but no one would claim it was
secure because of it.

Yes hypervisors are massively clever, and there are arguably valid use
cases (test environments, as mentioned earlier in a post I couldn't
find again when I looked, being an obvious one), but afaict they are
far from the panacea being presented to the modern IT department.

Please don't tell the HYPErvisor zealots, it'll break their hearts.


JF wrote:
"While Windows has never had a shortage of drivers, Linux has.
Commercial
VM engines basically provide drivers for hardware which Linux may not
have and pesent to Linux a device Linux knows about. It is a way to
fill
gaps that the "community" doesn't fill on Linux. "

Citation needed. It might well have been true ten years ago. You'd do
well to familiarise yourself with any modern Linux, and see if it
still holds true.

Quick one for Dave F:
Dave Froble also gets it. Dave has spotted (though he may not yet have
realised it) that in a few years time the industry will re-invent (and
maybe Google or Apple will patent) the microkernel.

On 09/09/12 16:48, John Wallace wrote:

> I don't know the internals of RasPi much but afaik the non-disclosed
> bits relate to NDA/licenced graphics and other non-beginner stuff. If
> I had time, RasPi might well be where I'd start.

I guess i'm thinking more of the  level of programming a bit
lower level than Pi, though you do need some h/w design knowledge to
do that. The problem with a more high level approach is that you may never
see the hardware in programming, which I would see as important to
really understand the whole process. That's also an area where there
are a greatest skill shortages, which could be usefull if you are trying
to stay in work long term :-). Many of the embedded linux people i've
spoken to seem clueless about the hardware, but someone has to write the
os: scheduling, drivers and file systems. Application programming is seen
as much less of a black art, but that's not really true at all.

>
> Or I'd carry on where I left off, on an old PC with an x86 Linux, but
> you never know *quite* what you're getting with an x86 PC and a random
> Linux, either with hardware or software.

If you want a really simple os, that runs on junk pc hardware and has books
describing it, Doug Comer's Xinu might be a good place to start. Years
old now, but an excellent intro to hardware, drivers and os design. It
was originally written for teaching an os course. There are versions that
run on Intel x86, 68k and even (yes) pdp11...

Regards,

Chris

JF Mezei wrote:
> David Froble wrote:
> 
>> As an example, would VMS have had such a hard time with video adapters, 
>> if the underlying "hardware handler" was handling the video adapters, 
>> not the OS?  For disk storage, why should an OS need to concern itself 
>> with anything lower level than "files"?
> 
> At the end of the day you still end up having to write a driver for
> every device. Whether that driver resides in the OS or in the VM, it is
> still there.
> 
> The more you shift from the OS to the VM, the more the VM becomes an
> operating system which ends up supporting multiple applications, just
> like real operating systems have been able to do for eons.

Well, yeah, without getting into arguing names and semantics, an OS for 
the particular hardware, and a consistent OS the users see, as much as 
they need to see anyway, that can run on multiple hardware platforms, 
perhaps all hardware platforms.

<snip>

> 
> There are valid uses for virtualised environents, And there are "hyped"
> uses for them.

Oh, yeah!

John Wallace wrote:

> Quick one for Dave F:
> Dave Froble also gets it. Dave has spotted (though he may not yet have
> realised it) that in a few years time the industry will re-invent (and
> maybe Google or Apple will patent) the microkernel.

To be honest, I'm not looking at it from the perspective of what's being 
done today, I'm looking at it from a clean sheet of paper perspective.

Look at disk storage.  It started with tracks and sectors.  Then we 
added the "file system", and users didn't need to bother with disk 
geometry.  Then we added things like ISAM files, and on to relational 
databases.  As we learn how to do things, we then figure out how to best 
build a "standard" way of doing those things.

Look at programming.  We've learned how to provide some structure, 
though, I'm sure there are many "structures" in use.

I'm also beginning to understand the claim someone made that any port of 
VMS to x86 should begin with a microkernel.  It's seems just another 
name for some division between code that interfaces with hardware, and 
code that provides other services.

Stephen Hoffman wrote:
> On 2012-09-09 19:20:02 +0000, David Froble said:
>>
>> After some research, at least I now understand what's being discussed. 
>> At least I think I do.  What it's done is send me off on what I think 
>> is a tangent, at least from how VM seems to be normally used.
>>
>> As some of you know, I "don't get out much", and haven't looked around 
>> at such things as Unix, Linux, and some others.  So my preconceptions 
>> are about how well I like VMS and all the things in weendoze that 
>> irritate me.
>>
>> This discussion has caused me to ask, why should an OS have to deal 
>> with devices?  An OS like VMS does vastly different things, one part 
>> dealing with devices, another memory (if it's not considered a 
>> device), and there is scheduling jobs, and providing other services.
>>
>> So I'm wondering about an environment where there is (Ok, I'll use 
>> Microsoft's term) something like a hardware abstraction layer that 
>> interacts with the hardware and provides services to an OS.  Don't 
>> everyone yell at me "hey dummy, that's been going on for a long 
>> time".  From my reading, IBM was doing similar things 50 years ago.  
>> Anyway, the thought was, if there was a standard for such an 
>> interface, then all OSs could be written to use the standard services.
> 
> There hasn't been a standard for devices, unfortunately.  Beyond 
> Windows, obviously.

It's far from a perfect world.

> As for porting the OS around, VMS doesn't have a defined abstraction layer.

And there are some of the questions.  Could such be done?  How 
hard/expensive?  What would be some of the serious ramifications?

> Though the operating system has gained much in portability since its VAX 
> days, certainly.

As in most things, we learn from doing, and hopefully apply that learning.

>> As an example, would VMS have had such a hard time with video 
>> adapters, if the underlying "hardware handler" was handling the video 
>> adapters, not the OS?
> 
> The VGA interface has been consistent, but there's not been much 
> consistency since then.
> 
>> For disk storage, why should an OS need to concern itself with 
>> anything lower level than "files"?
> 
> That's a common pattern on newer platforms; where directories aren't at 
> the forefront of the storage.

As mentioned, I don't get out much, and I still have a problem 
understanding this concept.  I'd feel that I'd need some way of seeing 
what I've placed on disk for subsequent use.  I've a problem with the 
concept of not having distinct files, and a "directory" of such.

> But as for why that can be a problem, there's I/O caching and I/O and 
> memory prefetching.   That's always a trade-off; whether that's closest 
> to the application, in the OS I/O system, the I/O controller and the 
> outboard storage controller.  VMS and VMS apps use all these.  Push that 
> down into the VM, and your cache efficiency can suffer.  Push it up into 
> the application, and you can chew through a whole lot of memory, and the 
> overhead of moving all that around.  And then there's the "fun" of 
> keeping all the caches consistent.

Here is where current practices would be a problem.  If you're talking 
about a VM with multiple instances of OSs running, do they want to 
access the same data?  Do they want to cooperate with some type of 
locking?  Do they want to share the cache?

If you want what you're calling the VM to just handle the hardware, that 
is simpler.  When you go for more, things aren't so easy.

I can't even begin to imagine what it would take for "going for more".

On 2012-09-09 22:12:53 +0000, David Froble said:

> I'm also beginning to understand the claim someone made that any port 
> of VMS to x86 should begin with a microkernel.  It's seems just another 
> name for some division between code that interfaces with hardware, and 
> code that provides other services.

If it's not already been posted, some related reading: 
<http://www.sture.ch/vms/Usenix_VMS-on-Mach.pdf>.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 09/09/12 22:12, David Froble wrote:

>
> I'm also beginning to understand the claim someone made that any port of
> VMS to x86 should begin with a microkernel. It's seems just another name
> for some division between code that interfaces with hardware, and code
> that provides other services.

I don't know how much you have read about os's in general, but one of 
the best
introductory books is one from the IBM Systems Programming series:

H M Dietel

An Introduction to Operating Systems

ISBN: 0-201-14473-5

It's an excellent introduction and covers just about everything you need for
a solid background, in plain english. Several os examples are described and
there's even a chapter on VMS.

You'll find it s/h on ABE for just a few $ most likely.

As for the kernel question, think of an os as a simplified set of layers:

Application -> Kernel -> Memory management
                       -> Device drivers -> Hardware interface -> Comms, 
networking, screen etc.
                       -> File system    -> hardware interface -> Storage
                       -> Process Scheduling

Regards,

Chris

On Sun, 09 Sep 2012 18:29:13 -0400, David Froble wrote:

> Stephen Hoffman wrote:
>> On 2012-09-09 19:20:02 +0000, David Froble said:
>> 
>>> For disk storage, why should an OS need to concern itself with
>>> anything lower level than "files"?
>> 
>> That's a common pattern on newer platforms; where directories aren't at
>> the forefront of the storage.
> 
> As mentioned, I don't get out much, and I still have a problem
> understanding this concept.  I'd feel that I'd need some way of seeing
> what I've placed on disk for subsequent use.  I've a problem with the
> concept of not having distinct files, and a "directory" of such.

Imagine that instead of files in directories you have "binary blobs" (for 
want of a better phrase) inside a database?

For example, do I really need my photo or music collections held as 
discrete files in directories with some form of indexing pointing to 
those files (I am thinking of what I currently use for this - iPhoto and 
iTunes, or other products on non-Apple platforms) or would they be better 
off in databases?

-- 
Paul Sture

On 2012-09-09 22:42:03 +0000, Paul Sture said:

> On Sun, 09 Sep 2012 18:29:13 -0400, David Froble wrote:
> 
>> Stephen Hoffman wrote:
>>> On 2012-09-09 19:20:02 +0000, David Froble said:
>>> 
>>>> For disk storage, why should an OS need to concern itself with
>>>> anything lower level than "files"?
>>> 
>>> That's a common pattern on newer platforms; where directories aren't at
>>> the forefront of the storage.
>> 
>> As mentioned, I don't get out much, and I still have a problem
>> understanding this concept.  I'd feel that I'd need some way of seeing
>> what I've placed on disk for subsequent use.  I've a problem with the
>> concept of not having distinct files, and a "directory" of such.
> 
> Imagine that instead of files in directories you have "binary blobs" (for
> want of a better phrase) inside a database?

Ayup.

A file system is inherently a database.  A hierarchical one.  And a 
very primitive one.

The application cares about a blob of data, and wants a "handle" 
available to access the blob, and the whole directory stuff exists just 
to allow the programmer or the user more spots to store stuff, and to 
organize it.  Or as happens as disks get bigger and more and more files 
become common, with spots to lose the blob.

With a typical database, the database deals with organizing the storage 
and the blobs for the application; your application has a "handle", and 
the database can fetch the blob for you.  The application doesn't care 
if the blob was on tape or disk or SSD or flash storage or in memory or 
replicated or compressed or whatever.  The app just wants the blob, and 
if the database hands it back (fast enough, and without errors), the 
application will be happy.  Extending this, the application can say 
"flush all the blobs associated with this second "handle" - I'll call 
it "directory", but it could well be "Tuesday's accounting run scratch 
blobs" or "The Foo Project" - as I don't need that data anymore.  And 
because it's a database, it could delete the data, or archive it, or 
audit it, or all the stuff you've seen and become familiar with using 
the current directories-n-files layout.  But - because it's a database 
- you can get good, consistent, backups, replication, and other such.


> For example, do I really need my photo or music collections held as
> discrete files in directories with some form of indexing pointing to
> those files (I am thinking of what I currently use for this - iPhoto and
> iTunes, or other products on non-Apple platforms) or would they be better
> off in databases?

Or as is available with some platforms, here's a whole wad of data 
structures (objects) I've built in memory, and the OS gets to figure 
out how to store it.  Either using the generic marshalling and 
unmarshalling where those are available, or using specific routines the 
programmer has written for specific structures.  Later, ask the OS to 
rebuild the data structures (objects).  This gets rid of whole piles of 
glue code.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 9/9/2012 6:10 AM, John Wallace wrote:
>
> "The hypervisor gives the guest operating system access to either a
> physical or an emulated set of disk drives.  Only the hypervisor knows
> or cares which. "
>
> How does device-level error logging get done in these cases?

The same as in a LUN presented by a SAN.  The OS generally sees either a 
perfect device or it gets a status of the device is offline.

> How might an OS under a hypervisor implement something like mount
> verification for device error recovery and high availability and
> predictive failure analysis?

Mount verification is simply asking the device it's status and some 
other information and then comparing it with the previously known status.

At the driver level on VMS it is known as a PACK-ACK, where it gets the
geometry of the device and then passes it up to a higher level.

The device driver does not know if a device is mounted, just if it can 
do I/O to it.

The upper level decides if the I/O needed to do a mount verification is 
needed.

> Taking it a step further, what about a crash dump analysis toolset,
> for post mortem debugging where "swap a card and wait till it happens
> again" (or even change a software config and wait till it happens
> again) isn't an option ? Are those things too out of fashion?

Hardware failures are the responsibility of the hypervisor and the 
diagnotics that it presents.  The guest OS no longer needs to care about 
most of the events.

The exception is that a hypervisor can work with an OS to let it know to 
power off unneeded components or to go to sleep, or when components are 
added or subtracted to the configuration.

> Feel free to extend the answer to the HyPervisor on IA64, not just
> volume-market x86 ones.

My answer is for the generic case.  Not all hypervisors are equal, and 
some features are not available for free for hobbyists to play with or 
require a minimum revision of x86_64 hardware.

> [I'm guessing the answer is it generally doesn't get done because it
> generally can't get done with the common hypervisor model, but even if
> these things are no longer important in the hype-driven trendy IT
> world, once upon a time some wise people used to think they were
> important...]

They are still important, but are obtained by monitoring the hypervisor 
instead of the guest or emulated operating system.

There are standards emerging for APIs for managing and monitoring the 
hypervisors.

It is the hypervisor's job to provide what appears to be the perfect 
hardware configuration and to track issues, and in some cases take 
corrective action like moving the OS to a different hypervisor host, or 
requesting a different SAN host handle the disk I/O.

There is no free lunch as the hypervisor has to be robust enough to 
handle the I/O of the guest, and it does add a new layer of expertise 
that is needed.  However this is the trend for x86 server deployment.

And I do recommend that any one doing computer management start studying 
how this all works.  There is money to be made there, and also money to 
be made selling "shovels" to the people who are convinced that there is 
"gold" there.

My current employer is in the "shovel" business for networking, and 
related cloud support, and we are hiring in many engineering and QA 
positions, and I get a significant bonus if I can refer someone that get 
hired.  No VMS in use, however we are an HP Alliance One partner.

As to why the discussion of hypervisors is in this thread, as asked by 
Dave F., there were related questions in the OpenVMS.org poll.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

On Mon, 10 Sep 2012 00:42:03 +0200, Paul Sture wrote:

> On Sun, 09 Sep 2012 18:29:13 -0400, David Froble wrote:
> 
>> Stephen Hoffman wrote:
>>> On 2012-09-09 19:20:02 +0000, David Froble said:
>>> 
>>>> For disk storage, why should an OS need to concern itself with
>>>> anything lower level than "files"?
>>> 
>>> That's a common pattern on newer platforms; where directories aren't
>>> at the forefront of the storage.
>> 
>> As mentioned, I don't get out much, and I still have a problem
>> understanding this concept.  I'd feel that I'd need some way of seeing
>> what I've placed on disk for subsequent use.  I've a problem with the
>> concept of not having distinct files, and a "directory" of such.
> 
> Imagine that instead of files in directories you have "binary blobs"
> (for want of a better phrase) inside a database?
> 
> For example, do I really need my photo or music collections held as
> discrete files in directories with some form of indexing pointing to
> those files (I am thinking of what I currently use for this - iPhoto and
> iTunes, or other products on non-Apple platforms) or would they be
> better off in databases?

Now extend that to what we currently know as text files, which are 
anything from command procedures to documentation to source code files to 
transaction logs.  The ability to index their contents is very useful 
indeed.

But let us not forget the lessons we have learned about locking up data 
in formats which make it hard to get that data out of or may become 
obsolete.

-- 
Paul Sture

In article <5048d9cd$0$1530$c3e8da3$92d0a893@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Or was the whole IO system for VMS so tied to the CSR way of doing
> things on VAX that it absolutely could not e changed ?

   In my experience, VAXen did care one way or the other about CSR.
   But they did need a memory mapped I/O model.

   Of course, if DEC could add vector instructions, they could add I/O
   instructions.  There were a lot of unused opcodes.

   By comparison, x86 have I/O instructions, but I've only seen memory
   mapped busses actually used.  Can someone site an x86 system that
   actually used I/O instrutions?

In article <5048ebfd$0$1931$c3e8da3$dd9697d2@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Is the concept of CSR pretty much standard across all operating systems,
> and all buses ?

   Not really, but the concept of some small area that can be written
   to to start a larger, possibly chained, set of transfers, is pretty
   much standard.  Even the DR780 on VAX used a set of registers
   to set up a potentially infinite transfer.

> 
> Let me rephrase the above: are the concepts used in Q-BUS basically
> common to all devices/buses even today, with the major difference the
> way they now automatically configure ?

   The idea of control and status in a few words, addresses for those,
   words, and interrupts when done is pretty much universal.  But those
   addresses don't have to be accessable using the same insgtructions
   as RAM.

Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:

(snip)
>   By comparison, x86 have I/O instructions, but I've only seen memory
>   mapped busses actually used.  Can someone site an x86 system that
>   actually used I/O instrutions?

As far as I know, all of them. DOS/Windows at least, and since the
same I/O cards are used for others...

The 8086 (and successors) have a 16 bit I/O address space in addition
to the data addressing space. In the ISA days, you often had to set
jumpers for the address for the card. PCI doesn't need jumpers, but
I believe that the addresses are still there.

PCI has three addressing space, a configuration space in addition
to the data and I/O space.

I presume that processors without a separate I/O space map it into
the data space somewhere.

-- glen

In article <dr7uh9-n7c.ln1@news1.chingola.ch>,
Paul Sture  <nospam@sture.ch> wrote:
>On Sat, 08 Sep 2012 16:30:30 +0000, ChrisQ wrote:
>
>> On 09/08/12 14:05, Paul Sture wrote:
>> 
>> 
>>> A dose of healthy scepticism is definitely called for when you hear
>>> some of the stuff spouted.
>>>
>>> http://www.dilbert.com/strips/comic/2012-05-25/
>>>
>>>
>> I'm sure it makes sense for some applications, but if it's all running
>> on a single hardware platform, you lose everything if that fails, or the
>> vm machine crashes. You can spread the risk a lot better by having
>> separate hardware for each major task, with separate os instance for
>> each.
>
>Um yes.  A recent Fedora upgrade brought with it a new kernel and 
>VirtualBox stopped working, taking out all my virtual clients :-)
>
>Fortunately it left 2 previous versions of the kernel available in the 
>boot menu, so I could select a compatible one at boot time.
>
>Before anyone makes the comment that Fedora is "bleeding edge", yes it 
>can be, and CentOS has been suggested as more suitable.  However CentOS 
>doesn't support the NIC on this system - I found an article (which I 
>cannot find now) stating that hardware build by the mainstream 
>manufacturers in recent years was probably supported but if you had a 
>self build system you might be out of luck.
>
>> I know it's the current fashion and it probably saves power on large
>> sites, but for small shops, I see more complication and less reliability
>> in terms of single point of failure...
>
>All your eggs in one basket maybe, but that brings us back to the single 
>point of failure mainframe too.
>
>-- 
>Paul Sture


What's the NIC, it may be as simple as updating a file with the PCI id
numbers so the device is recognised.

Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/

In article <k2i2se$fjb$1@dont-email.me>,
Stephen Hoffman  <seaohveh@hoffmanlabs.invalid> wrote:
>On 2012-09-09 03:51:49 +0000, JF Mezei said:
>
>> Stephen Hoffman wrote:
>> 

<snip>
>
>If a physical bus or bus adapter is malfunctioning, then the driver is 
>scrod.  This sort of thing was more common back in the Q-bus and UNIBUS 
>and earlier days, when an I/O or system bus could jam; it's why older 
>VAX systems had UNJAM commands.  That's much less common, now.  (And 
>I've encountered a malfunctioning UNIBUS Adapter (what was called a 
>UBA, or specifically a DW780); that can cause some seriously weird 
>problems.)
<snip>
>-- 
>Pure Personal Opinion | HoffmanLabs LLC
>

The DW780 was a bear to troubleshoot.

I did five years at DEC Field Service and they were about the worst VAX
SBI devices to troubleshoot and diagnose except for the SBI jumper
cables.

The logic for the Unibus adapter was spread across the (IIRC six) 
boards (four in the backplane plus the paddle card and front end terminator).
The diags had about a 25% call out rate for the right part of the UBA
since the signals were routed through everything.  

The AB and C Unibus cables between the UBA cabinet and the CPU cabinet
were a PITA  (major pain and often overlooked).  All in all I'd rather
troubleshoot 20 RH780 issues to 1 DW780 issue if I didn't have a full
spares kit with me.

Seems like the Unibus adapter was not designed to be serviced easily.

I still want to do halt, init  and unjam by habit booting SIMH.


Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/

Newbie question:

when at the VAX >>> prompt, I do a "deposit" of a value at a memory
address which corresponds to the CSR or vector of a device on the Q-BUS,
does this get deposited into normal memory by the CPU, and then picked
up by the bus hardware accessing the memory the same way the CPU would ?


Or are those addresses mapped to special hardware which looks like
memory to the CPU, but is actually part of the BUS hardware which will
then accept those values and send them along onto the right device on
the bus ?

On 2012-09-11 00:56:46 +0000, JF Mezei said:

> when at the VAX >>> prompt, I do a "deposit" of a value at a memory
> address which corresponds to the CSR or vector of a device on the Q-BUS,
> does this get deposited into normal memory by the CPU, and then picked
> up by the bus hardware accessing the memory the same way the CPU would ?

With a physical examine or physical deposit (as differentiated from an 
examine or deposit using virtual addressing), there is no "normal" 
memory here; it's the CSR that you're touching.

You can have virtual memory that references this stuff, by setting up 
the appropriate virtual-to-physical mapping in the page tables.

And on most VAX systems, the VAX console is using and running on the 
same VAX CPU as the rest of the box.

> Or are those addresses mapped to special hardware which looks like
> memory to the CPU, but is actually part of the BUS hardware which will
> then accept those values and send them along onto the right device on
> the bus ?

It's not particularly special hardware, but yes.  VAX sets aside a big 
block of physical address space for use as I/O space, and I/O space can 
have device CSRs and can contain memory that's based out on the I/O bus.

As for experimenting, if you're working on a Q-bus MicroVAX with a 
DEQNA, DELQA or compatible Ethernet controller, issue the console 
command:

>>> E/W/P/N:6 20001920

That's an examine command, with the word, physical and the next six 
address locations as qualifiers, with the examination starting at 
physical address 20001920.

From the output of that command, read off the six bytes of the Ethernet 
hardware address from the Ethernet controller ROM, reading the low byte 
from each word shown.


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-11 01:15:29 +0000, Stephen Hoffman said:

> On 2012-09-11 00:56:46 +0000, JF Mezei said:
> 
>> when at the VAX >>> prompt, I do a "deposit" of a value at a memory
>> address which corresponds to the CSR or vector of a device on the Q-BUS,

And FWIW, the interrupt vector is where the controller tickles the 
processor, when it needs attention.

There's no way to deposit to an address which corresponds to a vector, 
because that's not how the vector is implemented.

Yes, you might be able to set the interrupt vector by a deposit command 
into the right part of the CSR of certain specific Q-bus controllers, 
but there is no generic means to read the interrupt vector, and any 
display of the current interrupt vector setting by VMS is the desired 
vector setting and not the actual setting because, well, because you 
cannot read the interrupt vector of an arbitrary Q-bus board from the 
OpenVMS environment.



-- 
Pure Personal Opinion | HoffmanLabs LLC

In article <k2m3bh$b6n$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> Organization: A noiseless patient Spider

I see this often.  What does it mean?  Might make sense in the context 
of a web crawler, but as the Organization header in a newsgroup post?

(I must be missing some sort of in-joke.)

On 2012-09-11, Phillip Helbig---undress to reply 
<helbig@astro.multiCLOTHESvax.de> wrote:
> In article <k2m3bh$b6n$1@dont-email.me>, Stephen Hoffman
><seaohveh@hoffmanlabs.invalid> writes: 
>
>> Organization: A noiseless patient Spider
>
> I see this often.  What does it mean?  Might make sense in the context 
> of a web crawler, but as the Organization header in a newsgroup post?

A literary reference: Walt Whitman's poetry collection _Leaves of Grass_,
#208.  If you like poetry, and can either get a good translation, or read 
it in the original English, it's a classic.

>
> (I must be missing some sort of in-joke.)
>

On Tue, 11 Sep 2012 10:38:40 +0000, brad wrote:

> On 2012-09-11, Phillip Helbig---undress to reply
> <helbig@astro.multiCLOTHESvax.de> wrote:
>> In article <k2m3bh$b6n$1@dont-email.me>, Stephen Hoffman
>><seaohveh@hoffmanlabs.invalid> writes:
>>
>>> Organization: A noiseless patient Spider
>>
>> I see this often.  What does it mean?  Might make sense in the context
>> of a web crawler, but as the Organization header in a newsgroup post?
> 
> A literary reference: Walt Whitman's poetry collection _Leaves of
> Grass_,
> #208.  If you like poetry, and can either get a good translation, or
> read it in the original English, it's a classic.

Thanks for that.

>> (I must be missing some sort of in-joke.)

The reason you see it so often is that it is the default "Organization:" 
header supplied by the free news server eternal-september.org.

-- 
Paul Sture

In article <k2l1kb$6mu$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> As far as I know, all of them. DOS/Windows at least, and since the
> same I/O cards are used for others...

   I was under the impression that both EISA and PCI were accessed as
   memory mapped.

In article <504e8c50$0$1855$c3e8da3$dd9697d2@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Newbie question:
> 
> when at the VAX >>> prompt, I do a "deposit" of a value at a memory
> address which corresponds to the CSR or vector of a device on the Q-BUS,
> does this get deposited into normal memory by the CPU, and then picked
> up by the bus hardware accessing the memory the same way the CPU would ?

   "memory mapped" I/O is not done through RAM, it is done by the
   same operation that accessing RAM would use.  When you deposit things
   from the console at a physical address, it goes directly to that
   physical address.  The CPU does not copy memory mapped I/O access
   to/from any location in RAM.

> 
> Or are those addresses mapped to special hardware which looks like
> memory to the CPU, but is actually part of the BUS hardware which will
> then accept those values and send them along onto the right device on
> the bus ?

   The system bus, bus adapter, and I/O bus all work together so that
   when you access a physical address mapped to an I/O device register,
   the data gets to that device register.  This is similar to how the 
   system bus, memory adapter, and RAM all work together so that when you
   access a physical address mapped to RAM, the data gets to that RAM
   location.

   

Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:

(snip, I wrote)
>> As far as I know, all of them. DOS/Windows at least, and since the
>> same I/O cards are used for others...

>   I was under the impression that both EISA and PCI were accessed as
>   memory mapped.

PCI has three addressing spaces, (memory, I/O, and configuration).

You (the builder of the PCI bus interface) can map them any way 
they want into the processor address space.

Designers of PCI cards can use either memory or I/O space, or both.

(Configurations space is required, as that is how the addresses
for the others get set.)

As an extension to ISA, I would expect EISA to include I/O space,
but don't actually know that it does.

-- glen

In article <k2no1m$c7$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> You (the builder of the PCI bus interface) can map them any way 
> they want into the processor address space.

   I think that's my question.  All the PC designes I've seen map all
   the PCI bus spaces as memory spaces.  That is, the CPU uses the
   same instructions to access all three spaces, not the x86 I/O
   instructions.

   I don't have access to the Windows source, of course, but my
   now old books on writing Windows device drivers seem to imply 
   there were no x86 I/O instructions in the kernel.

Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:

(snip)

>   I think that's my question.  All the PC designes I've seen map all
>   the PCI bus spaces as memory spaces.  That is, the CPU uses the
>   same instructions to access all three spaces, not the x86 I/O
>   instructions.

From Windows 7, Control Panel, System, Device Manage,

select your favorite device, such as the display device,
then click the Resources tab.

That indicates the memory and I/O space allocated to the device.

>   I don't have access to the Windows source, of course, but my
>   now old books on writing Windows device drivers seem to imply 
>   there were no x86 I/O instructions in the kernel.

Not that I know Windows internals any more than you, but the I/O
instructions should be in the device drivers, not the kernel.

Booting starts out with BIOS calls until enough is loaded to get
some actual device drivers into memory and running.

SCSI boards have enough ROM to get started, and link through
the BIOS interrupts so that they can read the boot programs
as needed.

-- glen

Bob Koehler wrote:

>    The system bus, bus adapter, and I/O bus all work together so that
>    when you access a physical address mapped to an I/O device register,
>    the data gets to that device register.  

On my all mighty Microvax II with 16 megs of RAM,

I would access the SCSI (Dilog) board by:

D/P/L 20088004 80000001 ; setup IO map
D/P/L 20001F40 20 ; enable mapping
D/P/W 20001468 0 ; write IP to reset host adaptor
D/P/W 2000146A 3FFF  ; wrie keyword to initiate DMA
S 200 ; start virtual terminal driver


20001468 corresponded to a CSR address it was calculated based on the
DIP switches.

Since this was a machine with a 16 meg RAM limit, (so highest RAM
address was 00 FF FF FF,  is it correct to state that the IO address
space was purposefully placed above the machine's hard memory limit and
the memory controller would intercept any request for RAM above a
certain number and send tyem to the IO controller ?

Was this trick used for all VAXes ?

On 2012-09-12 00:12:36 +0000, JF Mezei said:

> Was this trick used for all VAXes ?

You'll want to look at the system memory maps for the particular layout.

The older VAX processors had system programming guides, and which have 
some of these details and other interesting trivia.  There is one for 
the KA630 at 
<http://www.vaxination.ca/vms/microvax/EK-KA630-UG-001_FEB86.PDF>   
These processor user guides can sometimes be hard to find; various 
processors never had these manuals, others are just hard to find.

Also see DEC Standard 32: <http://bitsavers.org/pdf/dec/vax/archSpec/>


-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-12 02:12, JF Mezei wrote:
> Bob Koehler wrote:
>
>>     The system bus, bus adapter, and I/O bus all work together so that
>>     when you access a physical address mapped to an I/O device register,
>>     the data gets to that device register.
>
> On my all mighty Microvax II with 16 megs of RAM,
>
> I would access the SCSI (Dilog) board by:
>
> D/P/L 20088004 80000001 ; setup IO map
> D/P/L 20001F40 20 ; enable mapping
> D/P/W 20001468 0 ; write IP to reset host adaptor
> D/P/W 2000146A 3FFF  ; wrie keyword to initiate DMA
> S 200 ; start virtual terminal driver
>
>
> 20001468 corresponded to a CSR address it was calculated based on the
> DIP switches.
>
> Since this was a machine with a 16 meg RAM limit, (so highest RAM
> address was 00 FF FF FF,  is it correct to state that the IO address
> space was purposefully placed above the machine's hard memory limit and
> the memory controller would intercept any request for RAM above a
> certain number and send tyem to the IO controller ?
>
> Was this trick used for all VAXes ?

It was fairly traditional to split the physical address space into two 
equal sized chunks in the VAXen. 0-1FFF FFFF was reserved for physical 
memory, while 2000 0000-3FFF FFFF was reserved for buses and other stuff.
But that is not really a global enforcement, but just a pattern many 
machines were designed with. You need to look at the specific machine to 
make sure.

Also, with the introduction of the NVAX, your total physical address 
space could be much larger, so it made sense to split it up in another 
way on machines based on that CPU.

But to point one (obvious) think out. I/O address space was not 
purposefully placed above the machine's hard memory limit. That is 
putting the cart before the horse. The machine only have one hard limit, 
and that is that the physical address space is 0-3FFF FFFF. In that 
total space you need to put both physical memory and all kind of I/O 
spaces. So you need to make a decision where in this memory space to 
place physical memory, and where to place I/O. Arbitrarily, DEC often 
choose to split the (physical) address space in half.

That leaves 512M for physical memory, and 512M for I/O space.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

In article <k2o5qf$58s$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> 
> (snip)
> 
>>   I think that's my question.  All the PC designes I've seen map all
>>   the PCI bus spaces as memory spaces.  That is, the CPU uses the
>>   same instructions to access all three spaces, not the x86 I/O
>>   instructions.
> 
> From Windows 7, Control Panel, System, Device Manage,
> 
> select your favorite device, such as the display device,
> then click the Resources tab.
> 
> That indicates the memory and I/O space allocated to the device.

   Having an I/O space doesn't mean having to use I/O instructions.
   VAXen all have an I/O space, and no I/O instructions.

> 
> Not that I know Windows internals any more than you, but the I/O
> instructions should be in the device drivers, not the kernel.

   Never met an OS where the device drivers were did not operate as 
   part of the kernel.
   

In article <504fd376$0$44374$c3e8da3$f017e9df@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Since this was a machine with a 16 meg RAM limit, (so highest RAM
> address was 00 FF FF FF,  is it correct to state that the IO address
> space was purposefully placed above the machine's hard memory limit and
> the memory controller would intercept any request for RAM above a
> certain number and send tyem to the IO controller ?

  The memory controller should ignore addresses outside of RAM address
  space.

  The bus adapter (when multiple busses were involved), or the I/O
  device controller board should be paying attention to addresses in
  it's range.
        
  In the case of the mighty MV II, the memory controller should ignore
  Qbus accesses for addresses above 00FFFFFF, and each I/O board should 
  ignore Qbus accesses outside each board's (usually) tiny space.

On 2012-09-10, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
>
>    By comparison, x86 have I/O instructions, but I've only seen memory
>    mapped busses actually used.  Can someone site an x86 system that
>    actually used I/O instrutions?
>

Yes. Most (all?) of them do, at least up to a few years ago. I don't know
for sure about the most recent PCs.

For example, the traditional serial and parallel ports on x86 machines are
accessed using I/O port instructions and not memory mapped instructions.

Traditional directly attached PS/2 keyboards are accessed using I/O ports
as well.

Although the number of devices accessed using I/O ports has decreased in
a major way in more modern systems, I would be very surprised if any
existing x86 system does not use I/O ports at some point during operation.

For example, does the x86 real time clock I/O port have a memory mapped
equivalent these days ? (I honestly don't know. It's been _many_ years
since I've been near that part of a x86 PC at bare metal level.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Bob Koehler wrote:

>   The bus adapter (when multiple busses were involved), or the I/O
>   device controller board should be paying attention to addresses in
>   it's range.

Does this mean that all memory accesses were sent to both the memory and
IO controllers, and each then decided if they had to deal with it ?

Or was it the CPU's logic which looked at a bit in the address to
determine whether to send the operation to the IO or memory controllers ?

On 2012-09-13 06:41, JF Mezei wrote:
> Bob Koehler wrote:
>
>>    The bus adapter (when multiple busses were involved), or the I/O
>>    device controller board should be paying attention to addresses in
>>    it's range.
>
> Does this mean that all memory accesses were sent to both the memory and
> IO controllers, and each then decided if they had to deal with it ?
>
> Or was it the CPU's logic which looked at a bit in the address to
> determine whether to send the operation to the IO or memory controllers ?

Both memory controller and some bus controller is sitting on some kind 
of CPU bus, and sees all transactions. Both memory and bus controllers 
only responds to transactions to addresses that they cares about, and 
leaves the others alone. No different than devices then sitting on the 
bus, or memory cards sitting on the memory bus.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On 2012-09-13 04:41:56 +0000, JF Mezei said:

> Bob Koehler wrote:
> 
>> The bus adapter (when multiple busses were involved), or the I/O
>> device controller board should be paying attention to addresses in
>> it's range.
> 
> Does this mean that all memory accesses were sent to both the memory and
> IO controllers, and each then decided if they had to deal with it ?

The requests from the CPU processed by the northbridge, and the 
northbridge sorts this out.

http://en.wikipedia.org/wiki/Northbridge_(computing)

> Or was it the CPU's logic which looked at a bit in the address to
> determine whether to send the operation to the IO or memory controllers ?

Not usually the CPU, though there are CPU-integrated northbridges around.

For the purposes of reading/writing memory or reading/writing to I/O 
space, the details here don't (usually) matter beyond the generic 
discussions of speeds and feeds and the architectural position of the 
target widget; that the widgets that are CPU-integrated (eg: cache, 
possibly a northbridge) are faster than the widgets on an (external) 
northbridge (eg: memory, possibly cache, faster buses), which is faster 
than the stuff on the southbridge 
<http://en.wikipedia.org/wiki/Southbridge_(computing)> (buses and 
particularly slower buses), and everything's faster than the junk I/O 
widgets that are usually hanging off the slowest bus hanging off the 
southbridge.

Again: this is basic computer architecture.  Wikipedia or those classes 
I've pointed to are your best resources, and read that KA630 CPU manual 
for how DEC architected that particular processor module.

-- 
Pure Personal Opinion | HoffmanLabs LLC

On 2012-09-13 13:21, Stephen Hoffman wrote:
> On 2012-09-13 04:41:56 +0000, JF Mezei said:
>
>> Bob Koehler wrote:
>>
>>> The bus adapter (when multiple busses were involved), or the I/O
>>> device controller board should be paying attention to addresses in
>>> it's range.
>>
>> Does this mean that all memory accesses were sent to both the memory and
>> IO controllers, and each then decided if they had to deal with it ?
>
> The requests from the CPU processed by the northbridge, and the
> northbridge sorts this out.
>
> http://en.wikipedia.org/wiki/Northbridge_(computing)
>
>> Or was it the CPU's logic which looked at a bit in the address to
>> determine whether to send the operation to the IO or memory controllers ?
>
> Not usually the CPU, though there are CPU-integrated northbridges around.
>
> For the purposes of reading/writing memory or reading/writing to I/O
> space, the details here don't (usually) matter beyond the generic
> discussions of speeds and feeds and the architectural position of the
> target widget; that the widgets that are CPU-integrated (eg: cache,
> possibly a northbridge) are faster than the widgets on an (external)
> northbridge (eg: memory, possibly cache, faster buses), which is faster
> than the stuff on the southbridge
> <http://en.wikipedia.org/wiki/Southbridge_(computing)> (buses and
> particularly slower buses), and everything's faster than the junk I/O
> widgets that are usually hanging off the slowest bus hanging off the
> southbridge.
>
> Again: this is basic computer architecture.  Wikipedia or those classes
> I've pointed to are your best resources, and read that KA630 CPU manual
> for how DEC architected that particular processor module.

All very true, except for the fact that no VAXen (as far as I know) ever 
had a chip called northbridge. :-)
But the north/south bridge chips are just bus controllers really, which 
do a rough sorting of accesses, and pass them on to the right next level 
(bus). Be that a memory bus, or an I/O bus. And the way the bridge does 
it is by just looking at the addresses.
No different than what you had on a VAX-11/780, except there everything 
was sorted out from the SBI bus, and on a uVAX II, you have a CPU bus on 
which the memory controller as well as the Qbus adapter sits. So yes, 
this is just basic computer architecture. All the modern names serves to 
muddy the water, but there is nothing new here.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

In article <50516415$0$11862$c3e8da3$cc4fe22d@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Does this mean that all memory accesses were sent to both the memory and
> IO controllers, and each then decided if they had to deal with it ?

   The address is sent in parallel on a bunch of wires on the bus.
   Everyone on the bus sees those wires and decides whether/how to
   respond.  Read/write is a different wire.  Data is on another set
   of wires.  Interrupt request is another wire.  At least that's the 
   basics of the typical bus.  Some busses have ways of reusing some
   wires.

> Or was it the CPU's logic which looked at a bit in the address to
> determine whether to send the operation to the IO or memory controllers ?

   Something on the CPU board did decide whether to access the system
   bus, or the alternate, such as the the board front cables, on some 
   VAXen.  Probably not the CPU chip itself.  Almost certainly hidden from
   software.

On Mon, 10 Sep 2012 19:29:53 +0000, Bill Pechter wrote:

> In article <dr7uh9-n7c.ln1@news1.chingola.ch>,
> Paul Sture  <nospam@sture.ch> wrote:

>>Before anyone makes the comment that Fedora is "bleeding edge", yes it
>>can be, and CentOS has been suggested as more suitable.  However CentOS
>>doesn't support the NIC on this system - I found an article (which I
>>cannot find now) stating that hardware build by the mainstream
>>manufacturers in recent years was probably supported but if you had a
>>self build system you might be out of luck. 
> 
> What's the NIC, it may be as simple as updating a file with the PCI id
> numbers so the device is recognised.

It's a RealTek model and a couple of years ago was new enough that MS 
hadn't included a patch for it in Windows Update (that came the following 
month). My network config says this:

RTL8111/8168B PCI Express Gigabit Ethernet controlle

-- 
Paul Sture

In article <lt0ki9-b131.ln1@news1.chingola.ch>,
Paul Sture  <nospam@sture.ch> wrote:
>On Mon, 10 Sep 2012 19:29:53 +0000, Bill Pechter wrote:
>
>> In article <dr7uh9-n7c.ln1@news1.chingola.ch>,
>> Paul Sture  <nospam@sture.ch> wrote:
>
>>>Before anyone makes the comment that Fedora is "bleeding edge", yes it
>>>can be, and CentOS has been suggested as more suitable.  However CentOS
>>>doesn't support the NIC on this system - I found an article (which I
>>>cannot find now) stating that hardware build by the mainstream
>>>manufacturers in recent years was probably supported but if you had a
>>>self build system you might be out of luck. 
>> 
>> What's the NIC, it may be as simple as updating a file with the PCI id
>> numbers so the device is recognised.
>
>It's a RealTek model and a couple of years ago was new enough that MS 
>hadn't included a patch for it in Windows Update (that came the following 
>month). My network config says this:
>
>RTL8111/8168B PCI Express Gigabit Ethernet controlle
>
>-- 
>Paul Sture


I've got one or two of those in the PCI bus version..
I'll take a look tonight and get it configured.
What CentOS version have you tried?

I know RHEL5.3 and Centos 5.3 should have this driver in it.

https://access.redhat.com/knowledge/articles/7558
How do I get network working on Red Hat Enterprise Linux 5.0 on the
AcerPower G31?
Last updated on 20 Sep 2009, 10:31 PM GMT

Release Found: Red Hat Enterprise Linux 5.0
Problem

The AcerPower G31 workstation requires a network driver, r8168, that is
not provided by Red Hat in Red Hat Enterprise Linux 5.0 to support the
Realtek RTL8111/8168B NIC.
Solution

Acer will provide the support for this driver. Visit the following URL
to download it: http://www.acer.co.in/drivers/redhat%20Drivers.zip

Update: As of May 2009, Acer India Pvt. Ltd. has worked with Red Hat to
re-certify the AcerPower G31 on Red Hat Enterprise Linux 5.3. The
Realtek RTL8111/8168B NIC now works without requiring the download and
configuration of the driver from Acer on Red Hat Enterprise Linux 5.3.

Hence the stated problem in this article only affects users of Red Hat
Enterprise Linux 5.0 on AcerPower G31, who are un-able to upgrade to 5.3
or later. Any issues with Acer provided drivers should be logged with
Acer India directly as Red Hat will only support the drivers shipped
within Red Hat Enterprise Linux 5.3 and later.
Product(s)

The url below has a fix for RedHat (and probably CentOS) recongnizing
the device as the wrong module.

http://www.recital.com/index.php?option=com_content&view=article&id=295:howto-resolve-realtek-r8168b-dropped-packet-problems-on-redhatcentos&catid=66:linux

I'll check my box at home tonight.

Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/