| Univac 90/30 DIAG instruction [message #407647] |
Mon, 26 April 2021 23:01  |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Are there any Univac 90/30 hardware gurus out there? I've been
corresponding with someone who's writing a 90/30 emulator (he
cut his teeth on a 9200/9300 emulator). He's gotten his hands
on an image of an OS/3 release, and managed to get the emulator
to run partway through the boot block. At this point it hits a
DIAG instruction (Univac actually gave opcode 0x83 a mnemonic,
unlike the IBM 360), and he doesn't know what to do with it.
Presumably it's inquiring into hardware information (at least
with the operands it's being fed). But like the IBM 360's
_Principles of Operation_, the instruction is only briefly
mentioned, and the corresponding Univac manuals also lack
a description of what it actually does.
I know that this is a really obscure request, but has anyone
had experience with programming the 90/30 down to the metal -
and remember any of it?
aTdHvAaNnKcSe...
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407651 is a reply to message #407647] |
Tue, 27 April 2021 01:01  |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Tuesday, April 27, 2021 at 1:02:08 PM UTC+10, Charlie Gibbs wrote:
> Are there any Univac 90/30 hardware gurus out there? I've been
> corresponding with someone who's writing a 90/30 emulator (he
> cut his teeth on a 9200/9300 emulator). He's gotten his hands
> on an image of an OS/3 release, and managed to get the emulator
> to run partway through the boot block. At this point it hits a
> DIAG instruction (Univac actually gave opcode 0x83 a mnemonic,
> unlike the IBM 360), and he doesn't know what to do with it.
> Presumably it's inquiring into hardware information (at least
> with the operands it's being fed). But like the IBM 360's
> _Principles of Operation_, the instruction is only briefly
> mentioned, and the corresponding Univac manuals also lack
> a description of what it actually does.
>
> I know that this is a really obscure request, but has anyone
> had experience with programming the 90/30 down to the metal -
> and remember any of it?
..
The 90/30 is an IBM/360 look-alike.
From the IBM 360 Principles of Operations manual (bit savers):
..
DIAGNOSE
83 I2 B1 D1
..
The CPU performs built-in diagnostic functions.
The purpose of the I2 field and the operand address
may be defined in greater detail for a particular CPU
and its appropriate diagnostic procedures. Similarly,
the number of low-order address bits which must be
zero is further specified for a particular CPU. When the
address does not have the required number of loworder
zeros, a specification exception causes a program
interruption.
The purpose of the diagnostic functions is verification
of proper functioning of the CPU equipment and
locating faulty components.
The DIAGNOSE is completed either by taking the next
sequential instruction or by obtaining a new psw from
location 112. The diagnostic procedure may affect the
problem, supervisor, and interruptable status of the
CPU, the condition code, and the contents of storage,
registers, and timer, as well as the progress of I/0
operations.
Some diagnostic functions turn on the test light on
the operator control section of the system control
panel.
Since the instruction is not intended for problemprogram
or supervisor-program use, DIAGNOSE has no
mnemonic.
Condition Code: The code is unpredictable.
Program Interruptions:
Privileged operation
Specification
Addressing
Status-Switching Exceptions
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407665 is a reply to message #407647] |
Tue, 27 April 2021 14:49 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> Are there any Univac 90/30 hardware gurus out there? I've been
> corresponding with someone who's writing a 90/30 emulator (he
> cut his teeth on a 9200/9300 emulator). He's gotten his hands
> on an image of an OS/3 release, and managed to get the emulator
> to run partway through the boot block. At this point it hits a
> DIAG instruction (Univac actually gave opcode 0x83 a mnemonic,
> unlike the IBM 360), and he doesn't know what to do with it.
> Presumably it's inquiring into hardware information (at least
> with the operands it's being fed). But like the IBM 360's
> _Principles of Operation_, the instruction is only briefly
> mentioned, and the corresponding Univac manuals also lack
> a description of what it actually does.
>
> I know that this is a really obscure request, but has anyone
> had experience with programming the 90/30 down to the metal -
> and remember any of it?
>
> aTdHvAaNnKcSe...
>
Why not just log it and ignore it, and see what happens, or doesn’t.
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407667 is a reply to message #407665] |
Tue, 27 April 2021 15:19 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> Are there any Univac 90/30 hardware gurus out there? I've been
>> corresponding with someone who's writing a 90/30 emulator (he
>> cut his teeth on a 9200/9300 emulator). He's gotten his hands
>> on an image of an OS/3 release, and managed to get the emulator
>> to run partway through the boot block. At this point it hits a
>> DIAG instruction (Univac actually gave opcode 0x83 a mnemonic,
>> unlike the IBM 360), and he doesn't know what to do with it.
>> Presumably it's inquiring into hardware information (at least
>> with the operands it's being fed). But like the IBM 360's
>> _Principles of Operation_, the instruction is only briefly
>> mentioned, and the corresponding Univac manuals also lack
>> a description of what it actually does.
>>
>> I know that this is a really obscure request, but has anyone
>> had experience with programming the 90/30 down to the metal -
>> and remember any of it?
>>
>> aTdHvAaNnKcSe...
>>
>
> Why not just log it and ignore it, and see what happens, or doesn’t.
Or single-instruct (or trace) the instructions following the DIAG
instruction and reverse-engineer it.
You might also want to ask on comp.sys.unisys.
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407668 is a reply to message #407665] |
Tue, 27 April 2021 16:14 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, April 28, 2021 at 4:49:20 AM UTC+10, Peter Flass wrote:
> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>> Are there any Univac 90/30 hardware gurus out there? I've been
>> corresponding with someone who's writing a 90/30 emulator (he
>> cut his teeth on a 9200/9300 emulator). He's gotten his hands
>> on an image of an OS/3 release, and managed to get the emulator
>> to run partway through the boot block. At this point it hits a
>> DIAG instruction (Univac actually gave opcode 0x83 a mnemonic,
>> unlike the IBM 360), and he doesn't know what to do with it.
>> Presumably it's inquiring into hardware information (at least
>> with the operands it's being fed). But like the IBM 360's
>> _Principles of Operation_, the instruction is only briefly
>> mentioned, and the corresponding Univac manuals also lack
>> a description of what it actually does.
>>
>> I know that this is a really obscure request, but has anyone
>> had experience with programming the 90/30 down to the metal -
>> and remember any of it?
>>
>> aTdHvAaNnKcSe...
>>
> Why not just log it and ignore it, and see what happens, or doesn’t.
..
It's sufficient to treat it as a no-op.
A DIAG instruction tests that the processor is working.
..
Of course, if you want the simulator to simulate a hardware error ...
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407673 is a reply to message #407647] |
Tue, 27 April 2021 18:12 |
|
|
Originally posted by: Bob Eager
On Tue, 27 Apr 2021 03:01:10 +0000, Charlie Gibbs wrote:
> But like the IBM 360's _Principles of Operation_, the instruction is
> only briefly mentioned, and the corresponding Univac manuals also
> lack a description of what it actually does.
As far as IBM goes...
I seem to remember using DIAG to access CP when I was testing an
foreign operating system in a VM.
So the definition is at least partly rooted in software.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407678 is a reply to message #407668] |
Tue, 27 April 2021 19:50 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-04-27, Robin Vowels <robin.vowels@gmail.com> wrote:
> On Wednesday, April 28, 2021 at 4:49:20 AM UTC+10, Peter Flass wrote:
>
>> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
[90/30 DIAG instruction]
>> Why not just log it and ignore it, and see what happens, or doesn’t.
>
> It's sufficient to treat it as a no-op.
> A DIAG instruction tests that the processor is working.
We thought so too - but the bootstrap loader seems to want to use it
for something, which is not something we expected to see.
> Of course, if you want the simulator to simulate a hardware error ...
That comes later. :-)
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407679 is a reply to message #407667] |
Tue, 27 April 2021 19:50 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-04-27, Scott Lurndal <scott@slp53.sl.home> wrote:
> Peter Flass <peter_flass@yahoo.com> writes:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> [90/30 DIAG instruction]
>>
>> Why not just log it and ignore it, and see what happens, or doesn’t.
>
> Or single-instruct (or trace) the instructions following the DIAG
> instruction and reverse-engineer it.
That assumes that we have a real 90/30 to play with. We don't, so
there's nothing to reverse-engineer. My confederate is writing an
emulator, and discovered a DIAG in the bootstrap code. Maybe it's
used to determine hardware configuration; we're assuming it returns
some sort of information used farther on in the boot process, but
we have no idea what.
> You might also want to ask on comp.sys.unisys.
Thanks for the pointer.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407681 is a reply to message #407673] |
Tue, 27 April 2021 21:30 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> writes:
> As far as IBM goes...
>
> I seem to remember using DIAG to access CP when I was testing an
> foreign operating system in a VM.
>
> So the definition is at least partly rooted in software.
three people came out to the univ to install (virtual machine) CP/67 at
the univ ... which I got to play with on the weekends. I rewrote and
optimized a large amount of CP/67 pathlengths ... originally focused
on improving OS/360 execution in virtual machine.
I was then playing with CMS and observed that its file i/o was always
the same (handled the same way, channel program handled the same way,
etc). I then defined a new CCW ... only used by CMS when running in
CP/67 virtual machine ... significantly cutting CP/67 pathlength for CMS
file i/o.
CSC people then criticized me for violating 360 principles of operation
(for CCW not defined in "real hardware") ... I needed to use diagnose
instruction ... operation is defined as machine/model specific ...
creating the abstraction that there is a "virtual machine CP/67"
specific 360 model (and corresponding diagnose instruction
implementation).
In the morph from CP67->VM370 there was lots of stuff that was dropped
and/or simplified (including some amount of the code I had done as
undergraduate) and CMS crippled from running on real machine (original
CMS developed on 360/40, before CP/40 was operational). Then the use of
DIAGNOSE for "virtual machine" specific model operations really took off
with VM370.
Part of presentation I had done for IBM user group meeting when
I was undergraduate at the univ. on some of the early kernel
rewrites I had done for OS/360 running in CP/67 virtual machine
(from old a.f.c. post)
http://www.garlic.com/~lynn/94.html#18
original CP/67 CPU for running the MFT14 benchmark was 534sec ... and
some early rewrites reduced it to 113sec, cutting 421 CPU secs.
trivia: I had taken two semester hr intro to fortran/computers and
within a year was hired fulltime to be responsible for IBM mainframe
systems. They had replaced the 709/1401 (709 ibsys tape->tape, with 1401
handling front end unit record, tape<->unit record) with 360/67
originally for tss/360. However tss/360 never really came to production
fruition so ran most of the time as 360/65 with os/360. student fortran
original ran under second on 709 and original on os/360 360/65 ran well
over a minute. I installed HASP and it cut elapsed time about in half. I
then started doing custom sysgens to optimize placement of files and PDS
members on disk for optimizing arm seek and multi-track search of PDS
directories ... getting nearly another 3-fold reduction in elapsed time
to 12.9secs. Never did get faster than 709 until installed UofWaterloo
WATFOR for student jobs.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407740 is a reply to message #407673] |
Wed, 28 April 2021 07:07 |
|
|
Originally posted by: Bob Eager
On Tue, 27 Apr 2021 22:12:37 +0000, Bob Eager wrote:
> On Tue, 27 Apr 2021 03:01:10 +0000, Charlie Gibbs wrote:
>
>> But like the IBM 360's _Principles of Operation_, the instruction is
>> only briefly mentioned, and the corresponding Univac manuals also lack
>> a description of what it actually does.
>
> As far as IBM goes...
>
> I seem to remember using DIAG to access CP when I was testing an foreign
> operating system in a VM.
>
> So the definition is at least partly rooted in software.
I remembered what I used it for. I found it useful to have an operator
command (on my system) that would carry out a CP command. So I added that
to the operator console code on my system, and used DIAG to forward it.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407741 is a reply to message #407679] |
Wed, 28 April 2021 07:17 |
|
|
Originally posted by: antispam
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2021-04-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>
>>>> [90/30 DIAG instruction]
>>>
>>> Why not just log it and ignore it, and see what happens, or doesn?t.
>>
>> Or single-instruct (or trace) the instructions following the DIAG
>> instruction and reverse-engineer it.
>
> That assumes that we have a real 90/30 to play with. We don't, so
> there's nothing to reverse-engineer. My confederate is writing an
> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
> used to determine hardware configuration; we're assuming it returns
> some sort of information used farther on in the boot process, but
> we have no idea what.
Actually, emulator gives excellent possiblities to reverse-engineer.
Of course to reverse-engineer program, to know what it expects.
Emulator may have traps on access to memory, so that you can
identify place that use data from DIAG. In principle one can
add more fancy feature, for example track and flag expressions
depending on unknown data and trap in places that definitely
need the data (like conditional branches).
--
Waldek Hebisch
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407742 is a reply to message #407679] |
Wed, 28 April 2021 07:45 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, April 28, 2021 at 9:50:26 AM UTC+10, Charlie Gibbs wrote:
> On 2021-04-27, Scott Lurndal <sc...@slp53.sl.home> wrote:
>
>> Peter Flass <peter...@yahoo.com> writes:
>>
>>> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>>>
>>>> [90/30 DIAG instruction]
>>>
>>> Why not just log it and ignore it, and see what happens, or doesn’t.
>>
>> Or single-instruct (or trace) the instructions following the DIAG
>> instruction and reverse-engineer it.
> That assumes that we have a real 90/30 to play with. We don't, so
> there's nothing to reverse-engineer. My confederate is writing an
> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
> used to determine hardware configuration; we're assuming it returns
> some sort of information used farther on in the boot process, but
> we have no idea what.
..
Maybe you should read the extract from the S/360 Principles of Operations
tyhat I posted right after your initial query:
..
"The purpose of the diagnostic functions is verification
of proper functioning of the CPU equipment and
locating faulty components."
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407743 is a reply to message #407681] |
Wed, 28 April 2021 07:53 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, April 28, 2021 at 11:30:52 AM UTC+10, ly...@garlic.com wrote:
> Bob Eager <news...@eager.cx> writes:
>> As far as IBM goes...
>>
>> I seem to remember using DIAG to access CP when I was testing an
>> foreign operating system in a VM.
>>
>> So the definition is at least partly rooted in software.
> three people came out to the univ to install (virtual machine) CP/67 at
> the univ ... which I got to play with on the weekends. I rewrote and
> optimized a large amount of CP/67 pathlengths ... originally focused
> on improving OS/360 execution in virtual machine.
>
> I was then playing with CMS and observed that its file i/o was always
> the same (handled the same way, channel program handled the same way,
> etc). I then defined a new CCW ... only used by CMS when running in
> CP/67 virtual machine ... significantly cutting CP/67 pathlength for CMS
> file i/o.
>
> CSC people then criticized me for violating 360 principles of operation
> (for CCW not defined in "real hardware") ... I needed to use diagnose
> instruction ... operation is defined as machine/model specific ...
> creating the abstraction that there is a "virtual machine CP/67"
> specific 360 model (and corresponding diagnose instruction
> implementation).
>
> In the morph from CP67->VM370 there was lots of stuff that was dropped
> and/or simplified (including some amount of the code I had done as
> undergraduate) and CMS crippled from running on real machine (original
> CMS developed on 360/40, before CP/40 was operational). Then the use of
> DIAGNOSE for "virtual machine" specific model operations really took off
> with VM370.
>
> Part of presentation I had done for IBM user group meeting when
> I was undergraduate at the univ. on some of the early kernel
> rewrites I had done for OS/360 running in CP/67 virtual machine
> (from old a.f.c. post)
> http://www.garlic.com/~lynn/94.html#18
>
> original CP/67 CPU for running the MFT14 benchmark was 534sec ... and
> some early rewrites reduced it to 113sec, cutting 421 CPU secs.
>
> trivia: I had taken two semester hr intro to fortran/computers and
> within a year was hired fulltime to be responsible for IBM mainframe
> systems. They had replaced the 709/1401 (709 ibsys tape->tape, with 1401
> handling front end unit record, tape<->unit record) with 360/67
> originally for tss/360. However tss/360 never really came to production
> fruition so ran most of the time as 360/65 with os/360. student fortran
> original ran under second on 709 and original on os/360 360/65 ran well
> over a minute. I installed HASP and it cut elapsed time about in half. I
> then started doing custom sysgens to optimize placement of files and PDS
> members on disk for optimizing arm seek and multi-track search of PDS
> directories ... getting nearly another 3-fold reduction in elapsed time
> to 12.9secs. Never did get faster than 709 until installed UofWaterloo
> WATFOR for student jobs.
..
WATFOR and PL/C were high-speed compilers designed specifically for
running student jobs. The problem with the IBM compilers was the
separate linkedit steps.
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407745 is a reply to message #407741] |
Wed, 28 April 2021 10:17 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
antispam@math.uni.wroc.pl writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>> On 2021-04-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>>
>>> Peter Flass <peter_flass@yahoo.com> writes:
>>>
>>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>>
>>>> > [90/30 DIAG instruction]
>>>>
>>>> Why not just log it and ignore it, and see what happens, or doesn?t.
>>>
>>> Or single-instruct (or trace) the instructions following the DIAG
>>> instruction and reverse-engineer it.
>>
>> That assumes that we have a real 90/30 to play with. We don't, so
>> there's nothing to reverse-engineer. My confederate is writing an
>> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
>> used to determine hardware configuration; we're assuming it returns
>> some sort of information used farther on in the boot process, but
>> we have no idea what.
>
> Actually, emulator gives excellent possiblities to reverse-engineer.
> Of course to reverse-engineer program, to know what it expects.
> Emulator may have traps on access to memory, so that you can
> identify place that use data from DIAG. In principle one can
> add more fancy feature, for example track and flag expressions
> depending on unknown data and trap in places that definitely
> need the data (like conditional branches).
Indeed. I used similar techniques to reverse engineer the
"READ UNIT STATUS" words from the magnetic tape controller
when writing the Burroughs medium systems simulator a few
years ago.
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407746 is a reply to message #407742] |
Wed, 28 April 2021 10:20 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2021-04-28, Robin Vowels <robin.vowels@gmail.com> wrote:
> On Wednesday, April 28, 2021 at 9:50:26 AM UTC+10, Charlie Gibbs wrote:
>
>> On 2021-04-27, Scott Lurndal <sc...@slp53.sl.home> wrote:
>>
>>> Peter Flass <peter...@yahoo.com> writes:
>>>
>>>> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>>>>
>>>> > [90/30 DIAG instruction]
>>>>
>>>> Why not just log it and ignore it, and see what happens, or doesn’t.
>>>
>>> Or single-instruct (or trace) the instructions following the DIAG
>>> instruction and reverse-engineer it.
>>
>> That assumes that we have a real 90/30 to play with. We don't, so
>> there's nothing to reverse-engineer. My confederate is writing an
>> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
>> used to determine hardware configuration; we're assuming it returns
>> some sort of information used farther on in the boot process, but
>> we have no idea what.
>
> Maybe you should read the extract from the S/360 Principles of Operations
> tyhat I posted right after your initial query:
>
> "The purpose of the diagnostic functions is verification
> of proper functioning of the CPU equipment and
> locating faulty components."
The POO also says that the function of the instruction varies
from model to model, and says nothing about any of them.
That's nowhere near describing what it actually does,
what data it leaves behind in what format, etc. We did
notice that the boot code loops on one condition code,
suggesting that it takes a while to gather whatever data
it's gathering.
--
/~\ Charlie Gibbs | They don't understand Microsoft
\ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked
X I'm really at ac.dekanfrus | a taxi in their driveway.
/ \ if you read it the right way. | -- Mayayana
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407748 is a reply to message #407742] |
Wed, 28 April 2021 11:32 |
|
|
Originally posted by: drb
> Maybe you should read the extract from the S/360 Principles of Operations
> tyhat I posted right after your initial query:
> .
> "The purpose of the diagnostic functions is verification
> of proper functioning of the CPU equipment and
> locating faulty components."
For all your snark, this ignores the fact that DIAG is heavily
used, at least in VM/CMS, as something akin to a system call.
De
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407751 is a reply to message #407746] |
Wed, 28 April 2021 13:26 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, April 29, 2021 at 12:21:29 AM UTC+10, Charlie Gibbs wrote:
> On 2021-04-28, Robin Vowels <robin....@gmail.com> wrote:
>
>> On Wednesday, April 28, 2021 at 9:50:26 AM UTC+10, Charlie Gibbs wrote:
>>
>>> On 2021-04-27, Scott Lurndal <sc...@slp53.sl.home> wrote:
>>>
>>>> Peter Flass <peter...@yahoo.com> writes:
>>>>
>>>> > Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>>>> >
>>>> >> [90/30 DIAG instruction]
>>>> >
>>>> > Why not just log it and ignore it, and see what happens, or doesn’t.
>>>>
>>>> Or single-instruct (or trace) the instructions following the DIAG
>>>> instruction and reverse-engineer it.
>>>
>>> That assumes that we have a real 90/30 to play with. We don't, so
>>> there's nothing to reverse-engineer. My confederate is writing an
>>> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
>>> used to determine hardware configuration; we're assuming it returns
>>> some sort of information used farther on in the boot process, but
>>> we have no idea what.
>>
>> Maybe you should read the extract from the S/360 Principles of Operations
>> tyhat I posted right after your initial query:
>>
>> "The purpose of the diagnostic functions is verification
>> of proper functioning of the CPU equipment and
>> locating faulty components."
..
> The POO also says that the function of the instruction varies
> from model to model, and says nothing about any of them.
..
It doesn't need to. DIAG is testing the proper functioning of the
equipment. The equipment will vary from processor to processor.
If all is well, execution continues with the next instruction.
..
> That's nowhere near describing what it actually does,
> what data it leaves behind in what format, etc.
..
It doesn't need to. The information is useful to a CE.
..
> We did
> notice that the boot code loops on one condition code,
> suggesting that it takes a while to gather whatever data
> it's gathering.
..
RTM. It says that the condition code is unpredictable.
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407752 is a reply to message #407748] |
Wed, 28 April 2021 13:32 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, April 29, 2021 at 1:32:22 AM UTC+10, Dennis Boone wrote:
>> Maybe you should read the extract from the S/360 Principles of Operations
>> tyhat I posted right after your initial query:
>> .
>> "The purpose of the diagnostic functions is verification
>> of proper functioning of the CPU equipment and
>> locating faulty components."
..
> For all your snark, this ignores the fact that DIAG is heavily
> used, at least in VM/CMS, as something akin to a system call.
..
That is surprising, since the time that DIAG takes will vary from
machine to machine.
..
You should RTM:
"Since the instruction is not intended for problemprogram
or supervisor-program use, DIAGNOSE has no
mnemonic."
..
Keep a civil tongue in your head.
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407753 is a reply to message #407751] |
Wed, 28 April 2021 14:34 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> On Thursday, April 29, 2021 at 12:21:29 AM UTC+10, Charlie Gibbs wrote:
>> On 2021-04-28, Robin Vowels <robin....@gmail.com> wrote:
>>
>>> On Wednesday, April 28, 2021 at 9:50:26 AM UTC+10, Charlie Gibbs wrote:
>>>
>>>> On 2021-04-27, Scott Lurndal <sc...@slp53.sl.home> wrote:
>>>>
>>>> > Peter Flass <peter...@yahoo.com> writes:
>>>> >
>>>> >> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>>>> >>
>>>> >>> [90/30 DIAG instruction]
>>>> >>
>>>> >> Why not just log it and ignore it, and see what happens, or doesn’t.
>>>> >
>>>> > Or single-instruct (or trace) the instructions following the DIAG
>>>> > instruction and reverse-engineer it.
>>>>
>>>> That assumes that we have a real 90/30 to play with. We don't, so
>>>> there's nothing to reverse-engineer. My confederate is writing an
>>>> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
>>>> used to determine hardware configuration; we're assuming it returns
>>>> some sort of information used farther on in the boot process, but
>>>> we have no idea what.
>>>
>>> Maybe you should read the extract from the S/360 Principles of Operations
>>> tyhat I posted right after your initial query:
>>>
>>> "The purpose of the diagnostic functions is verification
>>> of proper functioning of the CPU equipment and
>>> locating faulty components."
> .
>> The POO also says that the function of the instruction varies
>> from model to model, and says nothing about any of them.
> .
> It doesn't need to. DIAG is testing the proper functioning of the
> equipment. The equipment will vary from processor to processor.
> If all is well, execution continues with the next instruction.
> .
>> That's nowhere near describing what it actually does,
>> what data it leaves behind in what format, etc.
> .
> It doesn't need to. The information is useful to a CE.
> .
>> We did
>> notice that the boot code loops on one condition code,
>> suggesting that it takes a while to gather whatever data
>> it's gathering.
> RTM. It says that the condition code is unpredictable.
It may say it's unpredictable, but if there is code testing the
condition code and looping, clearly the writer of the code knew
that the condition code was conveying useful information.
Why not analyze the code trying to find the path you want the code to
take then have DIAG create whatever it takes to go down that path?
--
Dan Espen
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407754 is a reply to message #407743] |
Wed, 28 April 2021 14:36 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> WATFOR and PL/C were high-speed compilers designed specifically for
> running student jobs. The problem with the IBM compilers was the
> separate linkedit steps.
Step job scheduler (along with file open/close), I had gotten down to
less than four seconds ... i.e. part of it was the enormous number of
transient SVC pieces that it had to drag through the transient area.
three step with null steps, I had gotten down to under 12 seconds, which
was nearly all the elapsed time of student job fortg compile link edit
and go (execute).
WATFOR was single step monitor and could do multiple jobs in single step
.... so even if it didn't do anything, it was still almost four seconds
for the job scheduler step (and file open/close) overhead. What really
achieved its throughput was being able to batch a whole tray of student
job cards (around 30-60 cards/job) in one WATFOR run. WATFOR was rated
at 20,000 cards/min on 360/65 ... or 333 cards/sec. A tray of student
jobs was around 40-50 jobs/tray ... which took 5-6 seconds of WATFOR
time plus nearly 4 seconds for single step job scheduling overhead ... or
around 9-10 seconds total ... avg .2-.25 secs/job ... finally beating
709 tape->tape IBSYS. The job step overhead was nearly as much as the
actual WATFOR processing for whole tray of student jobs. If WATFOR had
run as separate os/360 step/job for each student program ... it would
have been four seconds.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407756 is a reply to message #407651] |
Wed, 28 April 2021 14:45 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> writes:
> The 90/30 is an IBM/360 look-alike.
> From the IBM 360 Principles of Operations manual (bit savers):
.... other (real hardware) 360 diagnose trivia ... on machines with
emulators ... 360/30 was microcoded machine and had microcode
implementing 360 instructions ... but could also have microcode
implementing 1401 ... and diagnose instruction (with approprirate
specification) could be used to switch into 1401 mode. Other 360s could
have other machine architecture microcode installed.
CP/67 (360/67) and VM/370 took advantage of model dependent diagnose
specification to implement functions that were described as for "virtual
machine" model.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407757 is a reply to message #407751] |
Wed, 28 April 2021 14:46 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Rod Speed, sometimes known as <robin.vowels@gmail.com> writes:
> On Thursday, April 29, 2021 at 12:21:29 AM UTC+10, Charlie Gibbs wrote:
> .
>> The POO also says that the function of the instruction varies=20
>> from model to model, and says nothing about any of them.
> .
> It doesn't need to. DIAG is testing the proper functioning of the
> equipment. The equipment will vary from processor to processor.
> If all is well, execution continues with the next instruction.
You have no personal knowledge of the subject - why do you
continue to expound incorrectly on the functionality associated
with the UNIVAC DIAG instruction?
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407758 is a reply to message #407748] |
Wed, 28 April 2021 16:29 |
|
|
Originally posted by: Bob Eager
On Wed, 28 Apr 2021 10:32:15 -0500, Dennis Boone wrote:
>> Maybe you should read the extract from the S/360 Principles of
>> Operations
>> tyhat I posted right after your initial query:
>> .
>> "The purpose of the diagnostic functions is verification of proper
>> functioning of the CPU equipment and locating faulty components."
>
> For all your snark, this ignores the fact that DIAG is heavily used, at
> least in VM/CMS, as something akin to a system call.
I did mention that. I used it from a foreign operating system running
under VM/XA.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407765 is a reply to message #407673] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Bob Eager <news0073@eager.cx> wrote:
> On Tue, 27 Apr 2021 03:01:10 +0000, Charlie Gibbs wrote:
>
>> But like the IBM 360's _Principles of Operation_, the instruction is
>> only briefly mentioned, and the corresponding Univac manuals also
>> lack a description of what it actually does.
>
> As far as IBM goes...
>
> I seem to remember using DIAG to access CP when I was testing an
> foreign operating system in a VM.
>
> So the definition is at least partly rooted in software.
>
VM “borrowed” the instruction for this, but that’s not an official use.
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407766 is a reply to message #407678] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2021-04-27, Robin Vowels <robin.vowels@gmail.com> wrote:
>
>> On Wednesday, April 28, 2021 at 4:49:20 AM UTC+10, Peter Flass wrote:
>>
>>> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>
> [90/30 DIAG instruction]
>
>>> Why not just log it and ignore it, and see what happens, or doesn’t.
>>
>> It's sufficient to treat it as a no-op.
>> A DIAG instruction tests that the processor is working.
>
> We thought so too - but the bootstrap loader seems to want to use it
> for something, which is not something we expected to see.
In that case it must be returning some indication of installed processor
features or memory size like some PCDOS BIOS calls. Do you have the source
for OS/3? A quick look at the source should tell you what it does. I
suppose it’s too much to hope that there is a logic manual.
>
>> Of course, if you want the simulator to simulate a hardware error ...
>
> That comes later. :-)
>
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407767 is a reply to message #407681] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> Bob Eager <news0073@eager.cx> writes:
>> As far as IBM goes...
>>
>> I seem to remember using DIAG to access CP when I was testing an
>> foreign operating system in a VM.
>>
>> So the definition is at least partly rooted in software.
>
> three people came out to the univ to install (virtual machine) CP/67 at
> the univ ... which I got to play with on the weekends. I rewrote and
> optimized a large amount of CP/67 pathlengths ... originally focused
> on improving OS/360 execution in virtual machine.
>
> I was then playing with CMS and observed that its file i/o was always
> the same (handled the same way, channel program handled the same way,
> etc). I then defined a new CCW ... only used by CMS when running in
> CP/67 virtual machine ... significantly cutting CP/67 pathlength for CMS
> file i/o.
>
> CSC people then criticized me for violating 360 principles of operation
> (for CCW not defined in "real hardware") ...
CMS hasn’t run on real hardware since forever. Now what you did would be
called “paravirtualization” and most VMMs use it to access host system
features, but I would assume my saying this is like telling The Dahli Lama
how to meditate.
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407768 is a reply to message #407743] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> wrote:
> On Wednesday, April 28, 2021 at 11:30:52 AM UTC+10, ly...@garlic.com wrote:
>> Bob Eager <news...@eager.cx> writes:
>>> As far as IBM goes...
>>>
>>> I seem to remember using DIAG to access CP when I was testing an
>>> foreign operating system in a VM.
>>>
>>> So the definition is at least partly rooted in software.
>> three people came out to the univ to install (virtual machine) CP/67 at
>> the univ ... which I got to play with on the weekends. I rewrote and
>> optimized a large amount of CP/67 pathlengths ... originally focused
>> on improving OS/360 execution in virtual machine.
>>
>> I was then playing with CMS and observed that its file i/o was always
>> the same (handled the same way, channel program handled the same way,
>> etc). I then defined a new CCW ... only used by CMS when running in
>> CP/67 virtual machine ... significantly cutting CP/67 pathlength for CMS
>> file i/o.
>>
>> CSC people then criticized me for violating 360 principles of operation
>> (for CCW not defined in "real hardware") ... I needed to use diagnose
>> instruction ... operation is defined as machine/model specific ...
>> creating the abstraction that there is a "virtual machine CP/67"
>> specific 360 model (and corresponding diagnose instruction
>> implementation).
>>
>> In the morph from CP67->VM370 there was lots of stuff that was dropped
>> and/or simplified (including some amount of the code I had done as
>> undergraduate) and CMS crippled from running on real machine (original
>> CMS developed on 360/40, before CP/40 was operational). Then the use of
>> DIAGNOSE for "virtual machine" specific model operations really took off
>> with VM370.
>>
>> Part of presentation I had done for IBM user group meeting when
>> I was undergraduate at the univ. on some of the early kernel
>> rewrites I had done for OS/360 running in CP/67 virtual machine
>> (from old a.f.c. post)
>> http://www.garlic.com/~lynn/94.html#18
>>
>> original CP/67 CPU for running the MFT14 benchmark was 534sec ... and
>> some early rewrites reduced it to 113sec, cutting 421 CPU secs.
>>
>> trivia: I had taken two semester hr intro to fortran/computers and
>> within a year was hired fulltime to be responsible for IBM mainframe
>> systems. They had replaced the 709/1401 (709 ibsys tape->tape, with 1401
>> handling front end unit record, tape<->unit record) with 360/67
>> originally for tss/360. However tss/360 never really came to production
>> fruition so ran most of the time as 360/65 with os/360. student fortran
>> original ran under second on 709 and original on os/360 360/65 ran well
>> over a minute. I installed HASP and it cut elapsed time about in half. I
>> then started doing custom sysgens to optimize placement of files and PDS
>> members on disk for optimizing arm seek and multi-track search of PDS
>> directories ... getting nearly another 3-fold reduction in elapsed time
>> to 12.9secs. Never did get faster than 709 until installed UofWaterloo
>> WATFOR for student jobs.
> .
> WATFOR and PL/C were high-speed compilers designed specifically for
> running student jobs. The problem with the IBM compilers was the
> separate linkedit steps.
>
Among other things. WATFOR (and PL/C, I believe) would batch compilations,
so they compiler loaded once, then compiled and ran all the jobs in a batch
before exiting, so they eliminated a whole raft of OS overhead in the
reader/interpreter, allocation, and open/close.
I’m still hoping that someone will turn up the source for PL/C someday. We
have an executable for PL/CT, but no source.
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407769 is a reply to message #407746] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2021-04-28, Robin Vowels <robin.vowels@gmail.com> wrote:
>
>> On Wednesday, April 28, 2021 at 9:50:26 AM UTC+10, Charlie Gibbs wrote:
>>
>>> On 2021-04-27, Scott Lurndal <sc...@slp53.sl.home> wrote:
>>>
>>>> Peter Flass <peter...@yahoo.com> writes:
>>>>
>>>> > Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>>>> >
>>>> >> [90/30 DIAG instruction]
>>>> >
>>>> > Why not just log it and ignore it, and see what happens, or doesn’t.
>>>>
>>>> Or single-instruct (or trace) the instructions following the DIAG
>>>> instruction and reverse-engineer it.
>>>
>>> That assumes that we have a real 90/30 to play with. We don't, so
>>> there's nothing to reverse-engineer. My confederate is writing an
>>> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
>>> used to determine hardware configuration; we're assuming it returns
>>> some sort of information used farther on in the boot process, but
>>> we have no idea what.
>>
>> Maybe you should read the extract from the S/360 Principles of Operations
>> tyhat I posted right after your initial query:
>>
>> "The purpose of the diagnostic functions is verification
>> of proper functioning of the CPU equipment and
>> locating faulty components."
>
> The POO also says that the function of the instruction varies
> from model to model, and says nothing about any of them.
> That's nowhere near describing what it actually does,
> what data it leaves behind in what format, etc. We did
> notice that the boot code loops on one condition code,
> suggesting that it takes a while to gather whatever data
> it's gathering.
>
Clear memory and return the size?
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407770 is a reply to message #407752] |
Wed, 28 April 2021 19:05 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Robin Vowels <robin.vowels@gmail.com> wrote:
> On Thursday, April 29, 2021 at 1:32:22 AM UTC+10, Dennis Boone wrote:
>>> Maybe you should read the extract from the S/360 Principles of Operations
>>> tyhat I posted right after your initial query:
>>> .
>>> "The purpose of the diagnostic functions is verification
>>> of proper functioning of the CPU equipment and
>>> locating faulty components."
> .
>> For all your snark, this ignores the fact that DIAG is heavily
>> used, at least in VM/CMS, as something akin to a system call.
> .
> That is surprising, since the time that DIAG takes will vary from
> machine to machine.
Except that CP traps it and does its own thing, it’s never actually
executed in this case.
> .
> You should RTM:
> "Since the instruction is not intended for problemprogram
> or supervisor-program use, DIAGNOSE has no
> mnemonic."
> .
> Keep a civil tongue in your head.
>
--
Pete
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407772 is a reply to message #407765] |
Wed, 28 April 2021 20:26 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Peter Flass <peter_flass@yahoo.com>:
> Bob Eager <news0073@eager.cx> wrote:
>> On Tue, 27 Apr 2021 03:01:10 +0000, Charlie Gibbs wrote:
>>
>>> But like the IBM 360's _Principles of Operation_, the instruction is
>>> only briefly mentioned, and the corresponding Univac manuals also
>>> lack a description of what it actually does.
>>
>> As far as IBM goes...
>>
>> I seem to remember using DIAG to access CP when I was testing an
>> foreign operating system in a VM.
>>
>> So the definition is at least partly rooted in software.
>>
>
> VM “borrowed” the instruction for this, but that’s not an official use.
Right -- VM virtualized the 370 architecture. Since diagnose was undefined other
than saying that it causes a privileged operation exception if the processor isn't
in supervisor state, it was the obvious place to put an escape to the hypervisor.
By the way, the 370/XA POO has this to say about diagnose:
The CPU performs built-in diagnostic
functions, or other model-dependent
functions. The purpose of the diagnos-
tic functions is to verify proper func-
tioning of equipment and to locate
faulty components. Other model-
dependent functions may include
disabling of failing buffers, reconfig-
uration of CPUs, storage, and channel
paths, and modification of control stor-
age.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407779 is a reply to message #407679] |
Thu, 29 April 2021 01:40 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
On 4/27/2021 6:50 PM, Charlie Gibbs wrote:
> On 2021-04-27, Scott Lurndal <scott@slp53.sl.home> wrote:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>
>>>> [90/30 DIAG instruction]
>>>
>>> Why not just log it and ignore it, and see what happens, or doesn’t.
>>
>> Or single-instruct (or trace) the instructions following the DIAG
>> instruction and reverse-engineer it.
>
> That assumes that we have a real 90/30 to play with. We don't, so
> there's nothing to reverse-engineer. My confederate is writing an
> emulator, and discovered a DIAG in the bootstrap code. Maybe it's
> used to determine hardware configuration; we're assuming it returns
> some sort of information used farther on in the boot process, but
> we have no idea what.
>
>> You might also want to ask on comp.sys.unisys.
>
> Thanks for the pointer.
>
a
There is this guy near Vancouver, Canada that knows a lot about old
Univac systems. His name is Charlie Gibbs and... Wait!!! You *are*
Charlie Gibbs!!! ;-)
"The hardest thing about growing old is watching knowledge die."
-- Charlie Gibbs
(According to interviews I saw, Don Knuth had the same problem with
finding master printers who could publish high quality copies of _The
Art of Computer Programming_ after volume three. All the master
printers who knew how that older technology worked.. had aged and died
out. :-( )
--
Charles Richmond
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407782 is a reply to message #407765] |
Thu, 29 April 2021 05:42 |
|
|
Originally posted by: Bob Eager
On Wed, 28 Apr 2021 16:05:06 -0700, Peter Flass wrote:
> Bob Eager <news0073@eager.cx> wrote:
>> On Tue, 27 Apr 2021 03:01:10 +0000, Charlie Gibbs wrote:
>>
>>> But like the IBM 360's _Principles of Operation_, the instruction is
>>> only briefly mentioned, and the corresponding Univac manuals also lack
>>> a description of what it actually does.
>>
>> As far as IBM goes...
>>
>> I seem to remember using DIAG to access CP when I was testing an
>> foreign operating system in a VM.
>>
>> So the definition is at least partly rooted in software.
>>
>>
> VM “borrowed” the instruction for this, but that’s not an official use.
Oh, I'm sure that's true. But the 'hardware definition' for VM presumably
documents what it does on that 'system'.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407788 is a reply to message #407769] |
Thu, 29 April 2021 11:04 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>
>>> "The purpose of the diagnostic functions is verification
>>> of proper functioning of the CPU equipment and
>>> locating faulty components."
>>
>> The POO also says that the function of the instruction varies
>> from model to model, and says nothing about any of them.
>> That's nowhere near describing what it actually does,
>> what data it leaves behind in what format, etc. We did
>> notice that the boot code loops on one condition code,
>> suggesting that it takes a while to gather whatever data
>> it's gathering.
>>
>
> Clear memory and return the size?
If it cleared memory, wouldn't the code running the DIAG
instruction also be cleared?
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407789 is a reply to message #407788] |
Thu, 29 April 2021 11:23 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
scott@slp53.sl.home (Scott Lurndal) writes:
> Peter Flass <peter_flass@yahoo.com> writes:
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>>>>
>>>> "The purpose of the diagnostic functions is verification
>>>> of proper functioning of the CPU equipment and
>>>> locating faulty components."
>>>
>>> The POO also says that the function of the instruction varies
>>> from model to model, and says nothing about any of them.
>>> That's nowhere near describing what it actually does,
>>> what data it leaves behind in what format, etc. We did
>>> notice that the boot code loops on one condition code,
>>> suggesting that it takes a while to gather whatever data
>>> it's gathering.
>>>
>>
>> Clear memory and return the size?
>
> If it cleared memory, wouldn't the code running the DIAG
> instruction also be cleared?
I doubt it clears memory and returns size.
Back in the day I had to diagnose the S/360 DOS
boot loader. Part of the boot loaders job was to clear
memory starting above the bootstrap routine up to high storage,
when the loop failed, that was high memory.
Newer models could have used DIAG for that, I just think it's unlikely.
--
Dan Espen
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407795 is a reply to message #407789] |
Thu, 29 April 2021 12:55 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Dan Espen <dan1espen@gmail.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> Peter Flass <peter_flass@yahoo.com> writes:
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>>> >
>>>> > "The purpose of the diagnostic functions is verification
>>>> > of proper functioning of the CPU equipment and
>>>> > locating faulty components."
>>>>
>>>> The POO also says that the function of the instruction varies
>>>> from model to model, and says nothing about any of them.
>>>> That's nowhere near describing what it actually does,
>>>> what data it leaves behind in what format, etc. We did
>>>> notice that the boot code loops on one condition code,
>>>> suggesting that it takes a while to gather whatever data
>>>> it's gathering.
>>>>
>>>
>>> Clear memory and return the size?
>>
>> If it cleared memory, wouldn't the code running the DIAG
>> instruction also be cleared?
>
> I doubt it clears memory and returns size.
> Back in the day I had to diagnose the S/360 DOS
> boot loader. Part of the boot loaders job was to clear
> memory starting above the bootstrap routine up to high storage,
> when the loop failed, that was high memory.
On the Burroughs mainframes, the maintenance processor cleared
memory before loading the bootstrap program into memory from
floppy disk. For the B7900, the maintenance processor was a
B5900; on the B4900, the maintenance processor was microprocessor
based (8080, IIRC).
|
|
|
|
| Re: rather far from Univac 90/30 DIAG instruction [message #407796 is a reply to message #407782] |
Thu, 29 April 2021 12:56 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
According to Bob Eager <news0073@eager.cx>:
>> VM “borrowed” the instruction for this, but that’s not an official use.
>
> Oh, I'm sure that's true. But the 'hardware definition' for VM presumably
> documents what it does on that 'system'.
Of course. It starts on page 257 of this manual:
http://bitsavers.org/pdf/ibm/370/VM_370/Release_3/GC20-1807- 4_VM370_System_Programmers_Guide_Rel_3_2-76.pdf
The functions are nothing like what a hardware diagnose would do. There were options to
manipulate the spool files for the virtual card reader and printer, to do disk I/O, to change
the size of the VM's memory, manage shared memory segments, and other stuff that makes sense
in a virtual machine but not on a real one.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
|
|
|
|
| Re: rather far from Univac 90/30 DIAG instruction [message #407797 is a reply to message #407796] |
Thu, 29 April 2021 14:29 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> writes:
> Of course. It starts on page 257 of this manual:
>
> http://bitsavers.org/pdf/ibm/370/VM_370/Release_3/GC20-1807- 4_VM370_System_Programmers_Guide_Rel_3_2-76.pdf
>
> The functions are nothing like what a hardware diagnose would do.
> There were options to manipulate the spool files for the virtual card
> reader and printer, to do disk I/O, to change the size of the VM's
> memory, manage shared memory segments, and other stuff that makes
> sense in a virtual machine but not on a real one.
even further ... it was what I got back from Cambridge when I created
new CCW to reduce the CP67 overhead specifically for CMS file i/o
.... that CP67 provided a virtual machine that conformed to 360
principles of operation. To provide something that didn't conform to 360
principles of operation ... had to be done via the "diagnose"
instruction ... which provided "model specific" features that weren't
defined in the 360 principles of operation (like on 360/30 which would
switch from microcode that implemented 360 to microcode that implemented
1401) ... but in this case it created the abstraction of a "virtual
machine" MODEL aka, CP67 provided a "virtual machine" 360 model
.... which was otherwise conformed to the 360 principles of operation ...
except for its (virtual machine) "model specific" functions provided by
the diagnose instruction (and the cp67 software effectively is the
microcode for the virtual machine 360 model).
when I graduated and joined the science center, one of my hobbies was
enhanced production operation systems for internal datacenters ...
including a page mapped file system for CMS.
some of the MIT CTSS people had gone to the 5th flr Project MAC and were
doing multics and other of the CTSS people went to the IBM science
center and were doing virtual machines, internal network (which was also
used in the 80s for the corporate sponsored univ. BITNET), bunch of
online apps, bunch of performance monitoring/modeling and capacity
planning, etc.
The 5th flr was doing single level store virtual memory filesystem for
multics ... and I figured I could do one also ... but I claimed I
learned what not to do watching the IBMers at the university trying to
get TSS/360 working (which also had single level store).
Some people spun off from the science center to form the vm370
development group, took over the ibm bostom programming center on the
3rd flr but rapidly outgrew that space and moved out to the empty former
SBC bldg on 128 at Burlington mall ... the morph from CP67->VM370
dropped and/or greatly simplified a lot of stuff from CP67 (including
lots of my stuff I did as undergraduate ... as well as the CP67
multiprocessor support).
IBM was then going thru the Future System period which was completely
different from 360/370 and was going to completely replace it (370 stuff
was being shutdown, the lack of new 370 stuff during the period is
credited with giving 370 clone mainframe vendors a market foothold) FS
also included flavor of (tss/360) single level store.
http://www.jfsowa.com/computer/ Some FS Comments
http://www.jfsowa.com/computer/memo125.htm Discussion of old FS evaluation
http://people.cs.clemson.edu/~mark/fs.html FS description and discussion
I continued to work on CP67 through the FS period and periodically I
would ridicule what they were doing (which wasn't exactly career
enhancing). Towards the end of the FS period I started migrating lots of
stuff from CP67 to VM370. Then when FS failed/imploded there was mad
rush to get stuff back into the 370 product pipeline ... kicking off
3033 (remapp of 370/168 logic to 20% faster chips) and 3081 were kicked
off in parallel. Also decision was to pick up some of the stuff that I
was shipping to internal datacenters for inclusion in VM370 release 3.
Inside IBM, anything related to FS got such a bad smell, including
single level store ... that they weren't going to do it ... so they
weren't going to ship my full CMS paged-mapped filesystem (although
implementation was completely different from TSS/360 and FS). A very
small subset of it was picked up for release 3, including a little stuff
for DCSS (discontiguous shared segments) mapped into DMKSNT (instead of
page mapped filesystem).
Also the CP67 reorg for kernel syncronization & serialization which
eliminated much of the VM370 failures & zombie users from the period (I
was doing a lot of synthetic workload benchmarking, moved to VM370 most
were guarantee to crash VM370 before I redid kernel syncronization and
serialization).
some old email from the period about moving from CP67 to VM370 for my
internal CSC/VM.
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430
Later in vm370 release 3, would ship a lot of CP67 performance and
resource management as well as the CP67 kernel organization needed for
mulitprocessor support (but the multiprocessor support didn't actually
ship until release 4)
Note things get a little more clouded in the last half of the 1980s when
"LPAR" support was added to 3090 (currently large percentage of IBM
mainframes run LPAR) ... bascially a whole lot of virtual machine
function was moved into the machine microcode ... providing the ability
to divide a real machine into multiple "Logical Partitions"
.... effectively a form of virtual machine w/o needing the VM370
software.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: rather far from Univac 90/30 DIAG instruction [message #407802 is a reply to message #407796] |
Thu, 29 April 2021 18:22 |
|
|
Originally posted by: Bob Eager
On Thu, 29 Apr 2021 16:56:40 +0000, John Levine wrote:
> According to Bob Eager <news0073@eager.cx>:
>>> VM “borrowed” the instruction for this, but that’s not an official
>>> use.
>>
>> Oh, I'm sure that's true. But the 'hardware definition' for VM
>> presumably documents what it does on that 'system'.
>
> Of course. It starts on page 257 of this manual:
>
> http://bitsavers.org/pdf/ibm/370/VM_370/Release_3/
GC20-1807-4_VM370_System_Programmers_Guide_Rel_3_2-76.pdf
>
> The functions are nothing like what a hardware diagnose would do. There
> were options to manipulate the spool files for the virtual card reader
> and printer, to do disk I/O, to change the size of the VM's memory,
> manage shared memory segments, and other stuff that makes sense in a
> virtual machine but not on a real one.
Aha. I must have read that at some point, and used DIAGNOSE 8.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407806 is a reply to message #407746] |
Thu, 29 April 2021 21:20 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Charlie Gibbs wrote:
> The POO also says that the function of the instruction varies
> from model to model, and says nothing about any of them.
> That's nowhere near describing what it actually does,
> what data it leaves behind in what format, etc. We did
> notice that the boot code loops on one condition code,
> suggesting that it takes a while to gather whatever data
> it's gathering.
>
Some of the FEMM and ALD documents for the IBM 360 on bitsavers have
descriptions of how the microcode environment is set up and listings of the
microcode, with some terse comments. One could try to look that up for the
IBM model closest to the Univac clone and see what it does. My guess is on
the smaller machines, it does only a few things. Depending on parameters,
it might give the size of main storage, presence of any emulators and number
of channels.
Despite the comments in the POO, I don't think it really "diagnoses"
anything, but it does allow access to some things that are not usually under
program control.
Jon
|
|
|
|
| Re: Univac 90/30 DIAG instruction [message #407807 is a reply to message #407766] |
Thu, 29 April 2021 21:28 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Peter Flass wrote:
> In that case it must be returning some indication of installed processor
> features or memory size like some PCDOS BIOS calls. Do you have the source
> for OS/3? A quick look at the source should tell you what it does. I
> suppose it’s too much to hope that there is a logic manual.
Oh, yes. IBM 360/30 had optional features such as commercial instruction
set (CIS) meaning decimal arithmetic, and scientific instruction set (SIS)
meaning floating point arithmetic. I think the storage protection was not
available on the /30, and was optional on the /40.
Jon
|
|
|
|
Members
Search
Help
Register
Login
Home
