| Re: IBM Programmer Aptitude Test [message #263371 is a reply to message #263316] |
Mon, 04 August 2014 03:09   |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 3 Aug 2014 14:52:33 +0000 (UTC)
cb@bobby.df.lth.se (Christian Brunschen) wrote:
> In article <53de35eb$4$fuzhry+tra$mr2ice@news.patriot.net>,
> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>> In <ppc1bb-hmc.ln1@sambook.reistad.name>, on 08/03/2014
>> at 09:42 AM, Morten Reistad <first@last.name> said:
>>
>>> Tracks Per Inch.
>>
>> There were no 2400' open-reel magnetic tapes with 1600 tracks per
>> inch. There were tapes with 7 or 9 tracks[1] evenly distributed over a
>> .5" tape and recorded at 200, 556, 800, 1600 and 6250 BPI.
>>
>>> 2400 feet * 1600 tracks/inch
>>
>> No such animal. The correct figure is 9 tracks.
>
> Tape track density appears to be measured in TPI, Tracks per Inch; bit
> density in BPI, Bits per Inch. Have a look for instance at
> <http://www.wtec.org/loyola/hdmem/final/ch4.pdf> . Also for instance
> this description of a "1600 TPI" tape reader,
> < http://www.computinghistory.org.uk/det/16968/Digi-Data-1600- tpi-tape-reader/
If memory serves correctly (and it has been a long time) TPI stood
for Transitions Per Inch, a spatial analogue of baud, not Tracks Per Inch.
There has never been a tape with 1600 Tracks Per Inch, track density was
more like 18 tracks per inch (9 tracks on half inch tape).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #263372 is a reply to message #263348] |
Mon, 04 August 2014 04:13 |
Ahem A Rivet's Shot
Messages: 4843
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 03 Aug 2014 16:02:08 -0400
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> I don't have one. USB data keys are much more convenient. But my 8 GB
> and 16 GB data keys hold a lot less than a 180 GB tape.
Those are old data keys, the biggest USB key I've seen to date is a
1TB USB 3.0 device it's expensive though at over €800, OTOH 128GB keys can
be had down to €35 (there's an enormous variation in price - some go for
over €100 for 128GB). I've started to see 128GB micro SD cards too which I
think is the highest density data storage currently available, much higher
density than 160GB tapes (although the tapes do have the edge in price).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #263375 is a reply to message #263371] |
Mon, 04 August 2014 07:17 |
osmium
Messages: 749
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
"Ahem A Rivet's Shot" wrote:
news:20140804080909.b072564b56b9af6386955579@eircom.net...
> On Sun, 3 Aug 2014 14:52:33 +0000 (UTC)
> cb@bobby.df.lth.se (Christian Brunschen) wrote:
>
>> In article <53de35eb$4$fuzhry+tra$mr2ice@news.patriot.net>,
>> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>>> In <ppc1bb-hmc.ln1@sambook.reistad.name>, on 08/03/2014
>>> at 09:42 AM, Morten Reistad <first@last.name> said:
>>>
>>>> Tracks Per Inch.
>>>
>>> There were no 2400' open-reel magnetic tapes with 1600 tracks per
>>> inch. There were tapes with 7 or 9 tracks[1] evenly distributed over a
>>> .5" tape and recorded at 200, 556, 800, 1600 and 6250 BPI.
>>>
>>>> 2400 feet * 1600 tracks/inch
>>>
>>> No such animal. The correct figure is 9 tracks.
>>
>> Tape track density appears to be measured in TPI, Tracks per Inch; bit
>> density in BPI, Bits per Inch. Have a look for instance at
>> <http://www.wtec.org/loyola/hdmem/final/ch4.pdf> . Also for instance
>> this description of a "1600 TPI" tape reader,
>> < http://www.computinghistory.org.uk/det/16968/Digi-Data-1600- tpi-tape-reader/
>
> If memory serves correctly (and it has been a long time) TPI stood
> for Transitions Per Inch, a spatial analogue of baud, not Tracks Per Inch.
> There has never been a tape with 1600 Tracks Per Inch, track density was
> more like 18 tracks per inch (9 tracks on half inch tape).
Sure, that makes very good sense in thinking of change on ones recording. I
guess I got out of the tape biz before anyone invented that unfortunate
abbreviation.
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #263387 is a reply to message #263369] |
Mon, 04 August 2014 09:48 |
rpw3
Messages: 191
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
stoat <fake@fake.org> wrote:
+---------------
| I suspect that tpi actually stands for transitions per inch,referring to
| the encoding, and would more-or-less be equivalent to bits per inch.
+---------------
Indeed. ISTR that early 7- & 9-track tapes were "556 BPI" and "800 BPI"
NRZI (Non-Return to Zero, Inverting), but when density on 9-track tapes
started going up vendors used fancier encodings -- PE (Phase Encoding),
GCR (Group Code Recording), etc. -- the terminology changed from using
"BPI" to "TPI" (as you suggest, meaning [magnetic flux] Transitions Per
Inch) and "FCI" (Flux Changes per Inch). IIRC, 1600 TPI used PE and
6250 FCI used GCR.
By using proper encoding (PE, RLL, GCR) that did not mandate flux changes
or transitions to occur on regular bit boundaries, it was possible to
encode a higher effective "user data bits per inch" than a naive count
of flux changes or transitions per inch would suggest, which may be why
they dropped the "BPI" usage.
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <http://rpw3.org/>
San Mateo, CA 94403
|
|
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #263415 is a reply to message #262342] |
Mon, 04 August 2014 13:48 |
Anne & Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> writes:
> the s/38 common filesystem pool scaled poorly ... just having to
> save/restore all data as single integral whole, was barely tolerable
> with a few disks ... but large mainframe system with 300 disks would
> require days for the operation.
re:
http://www.garlic.com/~lynn/2014i.html#72 IBM Programmer Aptitude Test
one of the issues with IBM channels was big disk farms. total channel
run lengths were restricted to 200ft support 3330 800kbyte/sec transfer
(which includes hand-shake for every byte transferred).
to move to 3880 disk controller , the went to "data streaming" which
support multiple byte transfer per hand-shake ... this allowed extended
maximum channel length to 400ft and 3mbyte/sec transfer rates (however,
the slower processor in 3880, significantly increased latency for
command & control processing operations compared to 3830 controller).
some of the big datacenters would have processor in middle of room with
200ft channel radius out in every direction ... about 125k sq ft. area
for disk farm. some datacenters were constrained enough that they
started doing devices on multiple floors arrayed around the processor.
big datacenters also tended to have multiple processors in
"loosely-coupled" configuration ... 3330 disks could connect to two
different 3830 controllers with string switch and each 3830 controller
could have four channel interfaces (allowing disk to be access by eight
different channels/processors). center of disk farm would then be a
circle (rather than point) ... with overlapping radius ... limiting
max. disk farm physical area for connectivity to all processors.
3880 & datastreaming channel then extended the radius to 400ft (channel
run) or about 502k sq ft. area (twice the radius, four times the area)
containing disk farm. however, disk data density also went way up
.... enormously increasing the total amount of data in some of these old
mainframe datacenters.
one of issues I've periodically mentioned doing channel extender and
fiber channel standard ... was moving the i/o program out to the remote
end to eliminate the end-to-end latency operations ... everything could
be continuously streamed, concurrently in both directions .... getting
aggregate, sustained data transfer much closer to media transfer rate.
recent posts mentioning 3830/3880 disk controlleres:
http://www.garlic.com/~lynn/2014c.html#88 Optimization, CPU time, and related issues
http://www.garlic.com/~lynn/2014d.html#90 Enterprise Cobol 5.1
http://www.garlic.com/~lynn/2014i.html#68 z/OS physical memory usage with multiple copies of same load module at different virtual addresses
http://www.garlic.com/~lynn/2014i.html#90 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014i.html#91 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014i.html#96 z/OS physical memory usage with multiple copies of same load module at different virtual addresses
http://www.garlic.com/~lynn/2014i.html#97 The SDS 92, its place in history?
http://www.garlic.com/~lynn/2014j.html#17 The SDS 92, its place in history?
posts mentioning FICON
http://www.garlic.com/~lynn/submisc.html#ficon
posts mentioning channel extender
http://www.garlic.com/~lynn/submisc.html#channel.extender
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #263425 is a reply to message #263369] |
Mon, 04 August 2014 16:03 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2014-08-04, stoat <fake@fake.org> wrote:
> On 4/08/14 8:32 am, Osmium wrote:
>
>> "Christian Brunschen" wrote:
>>
>>> And while it may not be particularly correct, the term "tpi" has been
>>> seen in use (perhaps used somewhat interchangeably with "bpi")
>>> elsewhere as well (see for instance
>>> < http://www.sunhelp.org/pipermail/rescue/2004-April/101947.ht ml>).
>>>
>>> I'm not saying it's a correct term; just that a cursory internet
>>> search indicates that the term seems to have been in used in the same
>>> eay that Morten was using it.
>
> I suspect that tpi actually stands for transitions per inch,referring to
> the encoding, and would more-or-less be equivalent to bits per inch.
That makes more sense than many of the things that have appeared in
this thread so far. On the other hand, it could be another of those
erroneous expressions that have unfortunately gained traction, like
"9600-baud modem" or "DB-9 serial connector".
--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #271305 is a reply to message #262398] |
Thu, 23 October 2014 17:32 |
Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On 2014-07-25 6:50 PM, Peter Flass wrote:
>
> IME it was often quicker to back up a whole pack with physical backup
> rather than several datasets with logical backup.
True, if your backing up everything, AND is the pack is near full,
then physical (image) backups of the pack are faster than
a full logical (by file) backup.
Some drawbacks:
1) it is even less time to do occasional full backups, with
more frequent incremental backups of what has changed.
2) of selected files is difficult to impossible from a tape
image of a full disk. In our experience, at Waterloo,
individual files needed to be restored because a user
fumble fingered something far more often that because
of disk failure
3) Hardware and software failures can and do cause damage
to file system structures that proceed to propagate, and
cause more damage (e.g. dual allocations).
If your image backup was done after the initial damage,
but before it was noticed, the restored files system
will again fall apart.
4) Image backups generally require that the pack(s),
and usually the system be offline during the backup
so partially you don't grab a image of file system
structures that are inconsistent (partially updated).
Logical backups can be done on a running system.
5) Logical backups can be restored to other disk
configurations.
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #271358 is a reply to message #271305] |
Fri, 24 October 2014 07:29 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Alan Bowler <atbowler@thinkage.ca> wrote:
> On 2014-07-25 6:50 PM, Peter Flass wrote:
>>
>> IME it was often quicker to back up a whole pack with physical backup
>> rather than several datasets with logical backup.
>
> True, if your backing up everything, AND is the pack is near full,
> then physical (image) backups of the pack are faster than
> a full logical (by file) backup.
>
> Some drawbacks:
>
> 1) it is even less time to do occasional full backups, with
> more frequent incremental backups of what has changed.
This takes longer to restore a whole pack, as you have to process a number
of tapes, although as you say in point 2 this is less frequent than
restoring individual files.
> 2) of selected files is difficult to impossible from a tape
> image of a full disk. In our experience, at Waterloo,
> individual files needed to be restored because a user
> fumble fingered something far more often that because
> of disk failure
> 3) Hardware and software failures can and do cause damage
> to file system structures that proceed to propagate, and
> cause more damage (e.g. dual allocations).
> If your image backup was done after the initial damage,
> but before it was noticed, the restored files system
> will again fall apart.
I never observed this on zOS, because "file structures" are much simpler.
> 4) Image backups generally require that the pack(s),
> and usually the system be offline during the backup
> so partially you don't grab a image of file system
> structures that are inconsistent (partially updated).
> Logical backups can be done on a running system.
IBM fixed this with "snapshot." The file is marked for backup and
subsequent writes go to alternate locations. You can then back up the
original file whenever you want and then free the hold and the flush the
old versions of the tracks that were updated.
> 5) Logical backups can be restored to other disk
> configurations.
--
Pete
|
|
|
|
| Re: IBM Programmer Aptitude Test [message #271409 is a reply to message #271358] |
Fri, 24 October 2014 16:36 |
Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
"Peter Flass" <peter_flass@yahoo.com> wrote in message
news:181839362435841638.672175peter_flass-yahoo.com@news.eternal-september.org...
> Alan Bowler <atbowler@thinkage.ca> wrote:
>> On 2014-07-25 6:50 PM, Peter Flass wrote:
>>>
>>> IME it was often quicker to back up a whole pack with physical backup
>>> rather than several datasets with logical backup.
>>
>> True, if your backing up everything, AND is the pack is near full,
>> then physical (image) backups of the pack are faster than
>> a full logical (by file) backup.
>>
>> Some drawbacks:
>>
>> 1) it is even less time to do occasional full backups, with
>> more frequent incremental backups of what has changed.
>
> This takes longer to restore a whole pack, as you have to process a number
> of tapes, although as you say in point 2 this is less frequent than
> restoring individual files.
>
Once at a PPoE, I accidentally deleted the source file of my FORTRAN77
program. Unfortunately, I had typed the whole thing in earlier in the day,
so there was *no* tape backup of the file. Fortunately, I had saved the
compiler listing file. So I just wrote a little program that would edit the
crap off the compiler listing and re-create my source file. That beat the
heck out of typing the whole source again!!!
--
numerist at aquaporin4 dot com
|
|
|
|
| Re: IBM S/360 - 370 [message #395987 is a reply to message #262280] |
Sat, 20 June 2020 23:53 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
> The 370 series was a practical architecture, although the performance
> of some of the lower models seems like it must have been intentionally
> crippled to not interfere with the /15x and /16x machine.
What do you mean, "practical architecture"?
While it has some exotic instructions (such as EDMK, TR, TRT etc),
it lacked practical or useful instructions such as:
Increment a binary integer
Increment a binary integer in storage;
generate a 32-bit binary constant using an immediate instruction;
increment a 32-bit binary number using an immediate instruction.
Such instructions existed on earlier machines ...
The base-displacement addressing model proved to be
an impediment, tying up valuable general registers;
instruction-relative addressing would have been far better.
|
|
|
|
| Re: IBM S/360 - 370 [message #395997 is a reply to message #395987] |
Sun, 21 June 2020 11:32 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
> The base-displacement addressing model proved to be
> an impediment, tying up valuable general registers;
> instruction-relative addressing would have been far better.
Base displacement addressing lets a program call a subroutine that might be
located at a far-away location in memory, such as, say, a resident library
routine. You can't do that with only program counter-relative addressing.
The 370 architecture is head and shoulders above the dog's breakfast that is x86.
John Savard
|
|
|
|
| Re: IBM S/360 - 370 [message #395998 is a reply to message #395987] |
Sun, 21 June 2020 12:17 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
In article <46debf5e-38d0-4dca-bce5-39dba266c357o@googlegroups.com>,
<robin.vowels@gmail.com> wrote:
> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>
>> The 370 series was a practical architecture, although the performance
>> of some of the lower models seems like it must have been intentionally
>> crippled to not interfere with the /15x and /16x machine.
>
> What do you mean, "practical architecture"?
One that is still in use every day, while nearly every other 1960s architecture is dead?
> While it has some exotic instructions (such as EDMK, TR, TRT etc),
> it lacked practical or useful instructions such as:
>
> Increment a binary integer
> Increment a binary integer in storage;
> generate a 32-bit binary constant using an immediate instruction;
> increment a 32-bit binary number using an immediate instruction.
If the integer was less than 24 bits you could use LA. Other than that
they seem to agree with you since S/390 has load and add immediate
with 16 bit values and relative branches. zSeries adds 32 bit
immediate versions of most RX instructions.
> Such instructions existed on earlier machines ...
>
> The base-displacement addressing model proved to be
> an impediment, tying up valuable general registers;
> instruction-relative addressing would have been far better.
Relative addressing is fine for branches but less so for data.
zSeries added 20 bit displacements to most B+D instructions and
a few relative addressed data instructions.
As far as I can tell, there were two motivations for based addressing
with 12 bit displacements which even in 1963 were pretty small. One
was to have an instruction format that worked reasonably well both on
small systems with 32K or 64K of memory and on large systems with a
megabyte or more. That worked well. They knew that programs would need
several base registers, but with 16 registers there were enough.
The other was that they imagined that since all memory references were
base-relative, they could move programs and data around by changing
the base registsters and didn't need relocation hardware. That was
wrong, because programs store pointers in memory, and you don't
generally know which which are the base registers. I believe that
APL\360 had very disciplined address management so it could move
users' data blocks around, but the code didn't move.
--
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: IBM S/360 - 370 [message #396000 is a reply to message #395997] |
Sun, 21 June 2020 13:21 |
|
|
Originally posted by: J. Clarke
On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
>
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
What leads you to believe that X86 does not have base-displacement
addressing?
|
|
|
|
| Re: IBM S/360 - 370 [message #396006 is a reply to message #395997] |
Sun, 21 June 2020 17:30 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
>
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
Fur Sure. System/360 is an “architecture” - it was designed. X86 is a
mishmash, it just growed.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396007 is a reply to message #395998] |
Sun, 21 June 2020 17:30 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
John Levine <johnl@taugh.com> wrote:
> In article <46debf5e-38d0-4dca-bce5-39dba266c357o@googlegroups.com>,
> <robin.vowels@gmail.com> wrote:
>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>
>>> The 370 series was a practical architecture, although the performance
>>> of some of the lower models seems like it must have been intentionally
>>> crippled to not interfere with the /15x and /16x machine.
>>
>> What do you mean, "practical architecture"?
>
> One that is still in use every day, while nearly every other 1960s architecture is dead?
>
>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>> it lacked practical or useful instructions such as:
>>
>> Increment a binary integer
>> Increment a binary integer in storage;
>> generate a 32-bit binary constant using an immediate instruction;
>> increment a 32-bit binary number using an immediate instruction.
>
> If the integer was less than 24 bits you could use LA. Other than that
> they seem to agree with you since S/390 has load and add immediate
> with 16 bit values and relative branches. zSeries adds 32 bit
> immediate versions of most RX instructions.
>
>> Such instructions existed on earlier machines ...
>>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Relative addressing is fine for branches but less so for data.
> zSeries added 20 bit displacements to most B+D instructions and
> a few relative addressed data instructions.
>
> As far as I can tell, there were two motivations for based addressing
> with 12 bit displacements which even in 1963 were pretty small. One
> was to have an instruction format that worked reasonably well both on
> small systems with 32K or 64K of memory and on large systems with a
> megabyte or more. That worked well. They knew that programs would need
> several base registers, but with 16 registers there were enough.
I learned early that any program that needed more than two base registers
for code was too big. I usually kept all modules to 4K.
>
> The other was that they imagined that since all memory references were
> base-relative, they could move programs and data around by changing
> the base registsters and didn't need relocation hardware. That was
> wrong, because programs store pointers in memory, and you don't
> generally know which which are the base registers. I believe that
> APL\360 had very disciplined address management so it could move
> users' data blocks around, but the code didn't move.
>
>
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396008 is a reply to message #396000] |
Sun, 21 June 2020 17:30 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
J. Clarke <jclarke.873638@gmail.com> wrote:
> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
>
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>>
>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
> What leads you to believe that X86 does not have base-displacement
> addressing?
>
It has just about everything except a usable set of registers. I count nine
just now, but ESP, EBP, and EIP are obviously not general-purpose, and the
rest have differences between them.
--
Pete
|
|
|
|
| Re: IBM S/360 - 370 [message #396011 is a reply to message #396008] |
Sun, 21 June 2020 18:34 |
|
|
Originally posted by: J. Clarke
On Sun, 21 Jun 2020 14:30:11 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>>>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>>>
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>>
>> What leads you to believe that X86 does not have base-displacement
>> addressing?
>>
>
> It has just about everything except a usable set of registers. I count nine
> just now, but ESP, EBP, and EIP are obviously not general-purpose, and the
> rest have differences between them.
It's kind of a mess because floating point was originally an add-in
and they try to maintain backward-compatibility. But at this point
there are 12 general purpose registers in 64-bit mode--the original 4
plus 8 new ones.
|
|
|
|
| Re: IBM S/360 - 370 [message #396013 is a reply to message #396000] |
Sun, 21 June 2020 21:48 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, June 21, 2020 at 11:21:19 AM UTC-6, J. Clarke wrote:
> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
> What leads you to believe that X86 does not have base-displacement
> addressing?
What led _him_ to believe that is presumably that it's called segment-offset
addressing on the x86.
Of course, though, the 370 was *better*, since you used numbered registers for
bases, so you were free to use several of them for whatever purposes you wanted,
where the use of the segment registers is limited on the x86 and you just have
one spare one to use for extra purposes.
John Savard
|
|
|
|
| Re: IBM S/360 - 370 [message #396014 is a reply to message #395987] |
Sun, 21 June 2020 21:53 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com wrote:
> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>
>> The 370 series was a practical architecture, although the performance
>> of some of the lower models seems like it must have been intentionally
>> crippled to not interfere with the /15x and /16x machine.
>
> What do you mean, "practical architecture"?
>
> While it has some exotic instructions (such as EDMK, TR, TRT etc),
> it lacked practical or useful instructions such as:
>
> Increment a binary integer
Acttually, I think you can use the load address instruction to do this.
You set base register to 0, the offset field to 1, and the index register
and destination register to the same register with the value to be
incremented. Some machines may limit the operand to a 24-bit field.
In fact, you can add a constant of 1 to 4095 this way.
> Increment a binary integer in storage;
Right, I don't think there's a way to do this in a single instruction.
> generate a 32-bit binary constant using an immediate instruction;
> increment a 32-bit binary number using an immediate instruction.
>
The 360 did not have "immediate" operands like a number of minicomputers.
But, it was common to have an up to 4096 byte block of constants somewhere,
you'd leave a register pointing to the block, and then any one of the 1024
fullwords in the block could be addressed with an RX instruction, where you
set the location of the constant in the offset field. The assembler had
features to make this VERY convenient.
> Such instructions existed on earlier machines ...
>
> The base-displacement addressing model proved to be
> an impediment, tying up valuable general registers;
> instruction-relative addressing would have been far better.
Instruction-relative addressing would have been a HUGE problem on the 360/30
with its byte-wide ALU. I think some of the design decisions were made so
as not to turn the 360/30 from a tortoise to a snail.
One huge issue for most 360's was that while object code files could be
located anywhere in memory and run by just setting the base register to the
first address, once a program had been RUN, it started using and storing
absolute addresses, and thus could no longer be relocated.
But, it would require subtracting the base address from the return address
when calling a subroutine, instead of just storing the absolute address.
Also, the scheme of saving the subroutine return address in a register
caused a LOT of program crashes and infinite loops. I find a stack call
system a lot better.
Jon
|
|
|
|
| Re: IBM S/360 - 370 [message #396016 is a reply to message #395997] |
Sun, 21 June 2020 23:29 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
A branch instruction can use the contents of a word as an address
(as is done now, and as has been done since the first S/360).
The word would be addressed with instruction-relative addressing.
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
|
|
|
|
| Re: IBM S/360 - 370 [message #396017 is a reply to message #395998] |
Sun, 21 June 2020 23:39 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 2:17:29 AM UTC+10, John Levine wrote:
> In article <46debf5e......@googlegroups.com>,
> <r......@gmail.com> wrote:
>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>
>>> The 370 series was a practical architecture, although the performance
>>> of some of the lower models seems like it must have been intentionally
>>> crippled to not interfere with the /15x and /16x machine.
>>
>> What do you mean, "practical architecture"?
>
> One that is still in use every day, while nearly every other 1960s architecture is dead?
>
>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>> it lacked practical or useful instructions such as:
>>
>> Increment a binary integer
>> Increment a binary integer in storage;
>> generate a 32-bit binary constant using an immediate instruction;
>> increment a 32-bit binary number using an immediate instruction.
>
> If the integer was less than 24 bits you could use LA. Other than that
> they seem to agree with you since S/390 has load and add immediate
> with 16 bit values and relative branches. zSeries adds 32 bit
> immediate versions of most RX instructions.
>
>> Such instructions existed on earlier machines ...
>>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Relative addressing is fine for branches but less so for data.
> zSeries added 20 bit displacements to most B+D instructions and
> a few relative addressed data instructions.
>
> As far as I can tell, there were two motivations for based addressing
> with 12 bit displacements which even in 1963 were pretty small. One
> was to have an instruction format that worked reasonably well both on
> small systems with 32K or 64K of memory and on large systems with a
> megabyte or more. That worked well.
No it didn't.
> They knew that programs would need
> several base registers, but with 16 registers there were enough.
No there weren't. The XPL compiler has available only 3 registers
for general arithmetic; the remainder are taken up with base addressing
and other addressing, and there are still not enough.
> The other was that they imagined that since all memory references were
> base-relative, they could move programs and data around by changing
> the base registsters and didn't need relocation hardware.
Did they ever do that?
> That was
> wrong, because programs store pointers in memory, and you don't
> generally know which which are the base registers. I believe that
> APL\360 had very disciplined address management so it could move
> users' data blocks around, but the code didn't move.
Other systems used a program base register, and programs
could be moved around, if required, without the user knowing
anything about it.
|
|
|
|
| Re: IBM S/360 - 370 [message #396018 is a reply to message #396014] |
Sun, 21 June 2020 23:50 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 11:53:42 AM UTC+10, Jon Elson wrote:
> r.......@gmail.com wrote:
>
>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>
>>> The 370 series was a practical architecture, although the performance
>>> of some of the lower models seems like it must have been intentionally
>>> crippled to not interfere with the /15x and /16x machine.
>>
>> What do you mean, "practical architecture"?
>>
>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>> it lacked practical or useful instructions such as:
>>
>> Increment a binary integer
> Acttually, I think you can use the load address instruction to do this.
No.
LA requires that the result be only 24 bits, and that the result be positive.
Anything above that is truncated.
And it does not set the condition code, so it's worthless for
that purpose.
> You set base register to 0, the offset field to 1, and the index register
> and destination register to the same register with the value to be
> incremented. Some machines may limit the operand to a 24-bit field.
> In fact, you can add a constant of 1 to 4095 this way.
How does that help?
>> Increment a binary integer in storage;
> Right, I don't think there's a way to do this in a single instruction.
>> generate a 32-bit binary constant using an immediate instruction;
>> increment a 32-bit binary number using an immediate instruction.
> The 360 did not have "immediate" operands like a number of minicomputers.
> But, it was common to have an up to 4096 byte block of constants somewhere,
> you'd leave a register pointing to the block, and then any one of the 1024
> fullwords in the block could be addressed with an RX instruction, where you
> set the location of the constant in the offset field. The assembler had
> features to make this VERY convenient.
>> Such instructions existed on earlier machines ...
>>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
> Instruction-relative addressing would have been a HUGE problem on the 360/30
> with its byte-wide ALU.
Not so.
The IAR would merely be used instead of a base register.
> I think some of the design decisions were made so
> as not to turn the 360/30 from a tortoise to a snail.
Again, not so.
That decision contributed to software bloat on the S/360.
> One huge issue for most 360's was that while object code files could be
> located anywhere in memory and run by just setting the base register to the
> first address, once a program had been RUN, it started using and storing
> absolute addresses, and thus could no longer be relocated.
>
> But, it would require subtracting the base address from the return address
> when calling a subroutine, instead of just storing the absolute address.
>
> Also, the scheme of saving the subroutine return address in a register
> caused a LOT of program crashes and infinite loops. I find a stack call
> system a lot better.
|
|
|
|
| Re: IBM S/360 - 370 [message #396019 is a reply to message #396016] |
Mon, 22 June 2020 00:36 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>
> A branch instruction can use the contents of a word as an address
> (as is done now, and as has been done since the first S/360).
> The word would be addressed with instruction-relative addressing.
Sounds to me like you are describing S/360 JUMP instructions.
They have been part of the architecture for a long time now.
They do an interesting trick, the jump offset must be even so the
displacement is shifted one bit before use.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396021 is a reply to message #396017] |
Mon, 22 June 2020 00:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 2:17:29 AM UTC+10, John Levine wrote:
>> In article <46debf5e......@googlegroups.com>,
>> <r......@gmail.com> wrote:
>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>
>>>> The 370 series was a practical architecture, although the
>>>> performance of some of the lower models seems like it must have
>>>> been intentionally crippled to not interfere with the /15x and
>>>> /16x machine.
>>>
>>> What do you mean, "practical architecture"?
>>
>> One that is still in use every day, while nearly every other 1960s
>> architecture is dead?
>>
>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>> it lacked practical or useful instructions such as:
>>>
>>> Increment a binary integer Increment a binary integer in storage;
>>> generate a 32-bit binary constant using an immediate instruction;
>>> increment a 32-bit binary number using an immediate instruction.
>>
>> If the integer was less than 24 bits you could use LA. Other than
>> that they seem to agree with you since S/390 has load and add
>> immediate with 16 bit values and relative branches. zSeries adds 32
>> bit immediate versions of most RX instructions.
>>
>>> Such instructions existed on earlier machines ...
>>>
>>> The base-displacement addressing model proved to be an impediment,
>>> tying up valuable general registers; instruction-relative addressing
>>> would have been far better.
>>
>> Relative addressing is fine for branches but less so for data.
>> zSeries added 20 bit displacements to most B+D instructions and a few
>> relative addressed data instructions.
>>
>> As far as I can tell, there were two motivations for based addressing
>> with 12 bit displacements which even in 1963 were pretty small. One
>> was to have an instruction format that worked reasonably well both on
>> small systems with 32K or 64K of memory and on large systems with a
>> megabyte or more. That worked well.
>
> No it didn't.
>
>> They knew that programs would need several base registers, but with
>> 16 registers there were enough.
>
> No there weren't. The XPL compiler has available only 3 registers for
> general arithmetic; the remainder are taken up with base addressing
> and other addressing, and there are still not enough.
>
>> The other was that they imagined that since all memory references
>> were base-relative, they could move programs and data around by
>> changing the base registsters and didn't need relocation hardware.
>
> Did they ever do that?
It's sort of basic that a S/360 program can load at any address.
Reentrant programs can be shared. The LE compilers can make reentrant
code.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396022 is a reply to message #396018] |
Mon, 22 June 2020 00:52 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 11:53:42 AM UTC+10, Jon Elson wrote:
>> r.......@gmail.com wrote:
>>
>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>
>>>> The 370 series was a practical architecture, although the performance
>>>> of some of the lower models seems like it must have been intentionally
>>>> crippled to not interfere with the /15x and /16x machine.
>>>
>>> What do you mean, "practical architecture"?
>>>
>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>> it lacked practical or useful instructions such as:
>>>
>>> Increment a binary integer
>
>> Acttually, I think you can use the load address instruction to do this.
>
> No.
> LA requires that the result be only 24 bits, and that the result be positive.
> Anything above that is truncated.
> And it does not set the condition code, so it's worthless for
> that purpose.
In 31 bit mode, LA is 31 bits.
In 64 bit mode, LA is 64 bits.
Current machines have a bunch of add immediate instructions.
Current machines even have a stack.
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396023 is a reply to message #396019] |
Mon, 22 June 2020 00:58 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
> r......@gmail.com writes:
>
>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>>>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>>
>> A branch instruction can use the contents of a word as an address
>> (as is done now, and as has been done since the first S/360).
>> The word would be addressed with instruction-relative addressing.
>
> Sounds to me like you are describing S/360 JUMP instructions.
No I'm not.
They are base-relative instructions, and suffer from the
the same range problems as all the other instructions
that use base-displacement addressing.
> They have been part of the architecture for a long time now.
Since c. 1966.
> They do an interesting trick, the jump offset must be even so the
> displacement is shifted one bit before use.
No they don't. The Bxx family (B, BH, BL etc) use base-displacement
addressing, and the displacement is never shifted.
|
|
|
|
| Re: IBM S/360 - 370 [message #396024 is a reply to message #396021] |
Mon, 22 June 2020 01:02 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 2:44:28 PM UTC+10, Dan Espen wrote:
> r......@gmail.com writes:
>
>> On Monday, June 22, 2020 at 2:17:29 AM UTC+10, John Levine wrote:
>>> In article <46debf5e......@googlegroups.com>,
>>> <r......@gmail.com> wrote:
>>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>>
>>>> > The 370 series was a practical architecture, although the
>>>> > performance of some of the lower models seems like it must have
>>>> > been intentionally crippled to not interfere with the /15x and
>>>> > /16x machine.
>>>>
>>>> What do you mean, "practical architecture"?
>>>
>>> One that is still in use every day, while nearly every other 1960s
>>> architecture is dead?
>>>
>>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>>> it lacked practical or useful instructions such as:
>>>>
>>>> Increment a binary integer Increment a binary integer in storage;
>>>> generate a 32-bit binary constant using an immediate instruction;
>>>> increment a 32-bit binary number using an immediate instruction.
>>>
>>> If the integer was less than 24 bits you could use LA. Other than
>>> that they seem to agree with you since S/390 has load and add
>>> immediate with 16 bit values and relative branches. zSeries adds 32
>>> bit immediate versions of most RX instructions.
>>>
>>>> Such instructions existed on earlier machines ...
>>>>
>>>> The base-displacement addressing model proved to be an impediment,
>>>> tying up valuable general registers; instruction-relative addressing
>>>> would have been far better.
>>>
>>> Relative addressing is fine for branches but less so for data.
>>> zSeries added 20 bit displacements to most B+D instructions and a few
>>> relative addressed data instructions.
>>>
>>> As far as I can tell, there were two motivations for based addressing
>>> with 12 bit displacements which even in 1963 were pretty small. One
>>> was to have an instruction format that worked reasonably well both on
>>> small systems with 32K or 64K of memory and on large systems with a
>>> megabyte or more. That worked well.
>>
>> No it didn't.
>>
>>> They knew that programs would need several base registers, but with
>>> 16 registers there were enough.
>>
>> No there weren't. The XPL compiler has available only 3 registers for
>> general arithmetic; the remainder are taken up with base addressing
>> and other addressing, and there are still not enough.
>>
>>> The other was that they imagined that since all memory references
>>> were base-relative, they could move programs and data around by
>>> changing the base registsters and didn't need relocation hardware.
>>
>> Did they ever do that?
>
> It's sort of basic that a S/360 program can load at any address.
Only if it uses Base-displacement addressing.
But programs cannot be shifted around in memory while the program
is being executed.
> Reentrant programs can be shared. The LE compilers can make reentrant
> code.
|
|
|
|
| Re: IBM S/360 - 370 [message #396025 is a reply to message #396022] |
Mon, 22 June 2020 01:04 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 2:52:52 PM UTC+10, Dan Espen wrote:
> r......@gmail.com writes:
>
>> On Monday, June 22, 2020 at 11:53:42 AM UTC+10, Jon Elson wrote:
>>> r.......@gmail.com wrote:
>>>
>>>> On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>>
>>>> > The 370 series was a practical architecture, although the performance
>>>> > of some of the lower models seems like it must have been intentionally
>>>> > crippled to not interfere with the /15x and /16x machine.
>>>>
>>>> What do you mean, "practical architecture"?
>>>>
>>>> While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>>> it lacked practical or useful instructions such as:
>>>>
>>>> Increment a binary integer
>>
>>> Acttually, I think you can use the load address instruction to do this.
>>
>> No.
>> LA requires that the result be only 24 bits, and that the result be positive.
>> Anything above that is truncated.
>> And it does not set the condition code, so it's worthless for
>> that purpose.
>
> In 31 bit mode, LA is 31 bits.
> In 64 bit mode, LA is 64 bits.
These were all afterthoughts.
> Current machines have a bunch of add immediate instructions.
>
> Current machines even have a stack.
These are all afterthoughts.
|
|
|
|
| Re: IBM S/360 - 370 [message #396026 is a reply to message #395997] |
Mon, 22 June 2020 01:43 |
Bob Martin
Messages: 157
Registered: August 2012
Karma: 0
|
Senior Member |
|
|
On 21 Jun 2020 at 15:32:39, Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
>
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
+1
OS/360 had non-blocking I/O from the off in 1964 (I was at the announcement).
When did X86 get it?
|
|
|
|
| Re: IBM S/360 - 370 [message #396028 is a reply to message #395997] |
Mon, 22 June 2020 04:09 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
>
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
The x86 was designed when microprocessor design and construction
were in their infancy. And the family was derived from even
earlier designs.
|
|
|
|
| Re: IBM S/360 - 370 [message #396029 is a reply to message #396026] |
Mon, 22 June 2020 04:13 |
Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
|
Senior Member |
|
|
On Monday, June 22, 2020 at 3:43:50 PM UTC+10, Bob Martin wrote:
> On 21 Jun 2020 at 15:32:39, Quadibloc <j......@ecn.ab.ca> wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, r.......@gmail.com wrote:
>>
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>>
>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
> +1
>
> OS/360 had non-blocking I/O from the off in 1964
OS/360 and the S/360 were not then in existence.
> (I was at the announcement).
> When did X86 get it?
Non-blocking I/O existed from at least 1958, if not before.
|
|
|
|
| Re: IBM S/360 - 370 [message #396030 is a reply to message #396028] |
Mon, 22 June 2020 04:37 |
|
|
Originally posted by: Bob Eager
On Mon, 22 Jun 2020 01:09:59 -0700, robin.vowels wrote:
> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com
>> wrote:
>>
>>> The base-displacement addressing model proved to be an impediment,
>>> tying up valuable general registers; instruction-relative addressing
>>> would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that
>> might be located at a far-away location in memory, such as, say, a
>> resident library routine. You can't do that with only program
>> counter-relative addressing.
>>
>> The 370 architecture is head and shoulders above the dog's breakfast
>> that is x86.
>
> The x86 was designed when microprocessor design and construction were in
> their infancy. And the family was derived from even earlier designs.
And it was designed to be backwards compatible. Quite a way.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
|
|
|
|
| Re: IBM S/360 - 370 [message #396035 is a reply to message #396013] |
Mon, 22 June 2020 09:12 |
|
|
Originally posted by: antispam
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Sunday, June 21, 2020 at 11:21:19 AM UTC-6, J. Clarke wrote:
>> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
>> What leads you to believe that X86 does not have base-displacement
>> addressing?
>
> What led _him_ to believe that is presumably that it's called segment-offset
> addressing on the x86.
>
> Of course, though, the 370 was *better*, since you used numbered registers for
> bases, so you were free to use several of them for whatever purposes you wanted,
> where the use of the segment registers is limited on the x86 and you just have
> one spare one to use for extra purposes.
Hmm, IFAICS you were first to bring x86 into this discussion. What
led _you_ to believe that anybody was thinking about x86?
There were mention of earlier machines, 1401 comes to mind as
machine with index registers and displacement large enough to
cover whole memory. I can understand while IBM thought to
base + short displacement is enough for 360, but in 370 era
they should know better. They corrected this rather late.
BTW. Apparently vendors love to repeat all mistakes. Most
current architectures are 64-bit capable, but I know of no
widely used architecture with 64-bit displacement for loads/stores
(and the same for relative jumps). Such displacements would be
used very rarely, but lack of them means that compiler either
must contain unpleasent extra logic or bomb on large modules.
--
Waldek Hebisch
|
|
|
|
| Re: IBM S/360 - 370 [message #396036 is a reply to message #396026] |
Mon, 22 June 2020 10:02 |
|
|
Originally posted by: antispam
Bob Martin <bob.martin@excite.com> wrote:
> On 21 Jun 2020 at 15:32:39, Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>
>>> The base-displacement addressing model proved to be
>>> an impediment, tying up valuable general registers;
>>> instruction-relative addressing would have been far better.
>>
>> Base displacement addressing lets a program call a subroutine that might be
>> located at a far-away location in memory, such as, say, a resident library
>> routine. You can't do that with only program counter-relative addressing.
>>
>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>
> +1
>
> OS/360 had non-blocking I/O from the off in 1964 (I was at the announcement).
> When did X86 get it?
You are comparing apples with oranges. Already 8080 had DMA channels
and interrupts as part of architecture.
Complaing that MS DOS (or IBM BIOS) did not support non-blocking I/O
is like complainng about limitations of CMS. In both cases
limitations were to simplify _software_ and were deemed reasonable
given intended applications.
BTW: It is probably more accurate to compare 8086 to microengine of
low end 360. 8086 was intended for control stuff and in particular
8086 code had to do "higher level" functions that would be
implemented in microcode on designs using dedicated microengine.
Looking from this point of view, rather litte extra hardware
would turn early PC in slow 360. Basicaly, one would have to
and emulation code (extra ROM) and small glue electronics to
interface with IBM control units in the way 360 channels did.
Of course, due to emulation CPU speed would be poor, probably
4-5 times slower than 360/30. Also multiplexer chanel would
have lower capacity. But thanks to DMA chip selector chanel
would be faster than real 360/30.
Programmed natively, while less nice as architecture PC hardware
is for most applications more powerful than 360/30, with
notable exception of driving several low/middle speed peripherials
where multiplexer chanel would win.
--
Waldek Hebisch
|
|
|
|
| Re: IBM S/360 - 370 [message #396037 is a reply to message #395997] |
Mon, 22 June 2020 10:37 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>
>> The base-displacement addressing model proved to be
>> an impediment, tying up valuable general registers;
>> instruction-relative addressing would have been far better.
>
> Base displacement addressing lets a program call a subroutine that might be
> located at a far-away location in memory, such as, say, a resident library
> routine. You can't do that with only program counter-relative addressing.
>
> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
Only if you compare it with the 8088. A modern intel processor is as
capable as any modern z-series processor. A flat 64-bit address space is
much easier to use efficiently when compared to any segmented architecture.
|
|
|
|
| Re: IBM S/360 - 370 [message #396041 is a reply to message #396008] |
Mon, 22 June 2020 10:43 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
Peter Flass <peter_flass@yahoo.com> writes:
> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Sun, 21 Jun 2020 08:32:39 -0700 (PDT), Quadibloc
>> <jsavard@ecn.ab.ca> wrote:
>>
>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>
>>>> The base-displacement addressing model proved to be
>>>> an impediment, tying up valuable general registers;
>>>> instruction-relative addressing would have been far better.
>>>
>>> Base displacement addressing lets a program call a subroutine that might be
>>> located at a far-away location in memory, such as, say, a resident library
>>> routine. You can't do that with only program counter-relative addressing.
>>>
>>> The 370 architecture is head and shoulders above the dog's breakfast that is x86.
>>
>> What leads you to believe that X86 does not have base-displacement
>> addressing?
>>
>
> It has just about everything except a usable set of registers. I count nine
> just now, but ESP, EBP, and EIP are obviously not general-purpose, and the
> rest have differences between them.
General Purpose: %RAX, %RBX, $RCX, %RDX, %EBP (which is used as a general
purpose register in optimized code),,%rdi, %rsi, %r8, %r9, %r11, %r12, %r13, %r14, %r15.
That's fourteen 64-bit general purpose registers on x86 when running in 64-bit (long)
mode; and that's not even counting any of the SIMD/FP registers (16 128+ bit registers).
While %rsi/%rdi are also used by the string instructions implicitly, they're available
for general purpose use otherwise. And Intel discourages use of the string instructions
in the optimization guide.
|
|
|
|
|
|
| Re: IBM S/360 - 370 [message #396043 is a reply to message #396023] |
Mon, 22 June 2020 11:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 2:36:52 PM UTC+10, Dan Espen wrote:
>> r......@gmail.com writes:
>>
>>> On Monday, June 22, 2020 at 1:32:41 AM UTC+10, Quadibloc wrote:
>>>> On Saturday, June 20, 2020 at 9:53:12 PM UTC-6, robin...@gmail.com wrote:
>>>>
>>>> > The base-displacement addressing model proved to be
>>>> > an impediment, tying up valuable general registers;
>>>> > instruction-relative addressing would have been far better.
>>>>
>>>> Base displacement addressing lets a program call a subroutine that might be
>>>> located at a far-away location in memory, such as, say, a resident library
>>>> routine. You can't do that with only program counter-relative addressing.
>>>
>>> A branch instruction can use the contents of a word as an address
>>> (as is done now, and as has been done since the first S/360).
>>> The word would be addressed with instruction-relative addressing.
>>
>> Sounds to me like you are describing S/360 JUMP instructions.
>
> No I'm not.
> They are base-relative instructions, and suffer from the
> the same range problems as all the other instructions
> that use base-displacement addressing.
>
>> They have been part of the architecture for a long time now.
>
> Since c. 1966.
>
>> They do an interesting trick, the jump offset must be even so the
>> displacement is shifted one bit before use.
>
> No they don't. The Bxx family (B, BH, BL etc) use base-displacement
> addressing, and the displacement is never shifted.
I suggest you download a current POP manual and read about Branch Relative
instructions.
Here's one:
Branch relative on Condition Long:
The contents of the RI2 field are a signed binary inte-
ger specifying the number of halfwords that is added
to the address of the instruction to generate the
branch address.
(The RI2 field is bits 16-47.)
--
Dan Espen
|
|
|
|
| Re: IBM S/360 - 370 [message #396044 is a reply to message #396024] |
Mon, 22 June 2020 11:46 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
robin.vowels@gmail.com writes:
> On Monday, June 22, 2020 at 2:44:28 PM UTC+10, Dan Espen wrote:
>> r......@gmail.com writes:
>>
>>> On Monday, June 22, 2020 at 2:17:29 AM UTC+10, John Levine wrote:
>>>> In article <46debf5e......@googlegroups.com>,
>>>> <r......@gmail.com> wrote:
>>>> >On Friday, July 25, 2014 at 6:52:05 AM UTC+10, Jon Elson wrote:
>>>> >
>>>> >> The 370 series was a practical architecture, although the
>>>> >> performance of some of the lower models seems like it must have
>>>> >> been intentionally crippled to not interfere with the /15x and
>>>> >> /16x machine.
>>>> >
>>>> >What do you mean, "practical architecture"?
>>>>
>>>> One that is still in use every day, while nearly every other 1960s
>>>> architecture is dead?
>>>>
>>>> >While it has some exotic instructions (such as EDMK, TR, TRT etc),
>>>> >it lacked practical or useful instructions such as:
>>>> >
>>>> >Increment a binary integer Increment a binary integer in storage;
>>>> >generate a 32-bit binary constant using an immediate instruction;
>>>> >increment a 32-bit binary number using an immediate instruction.
>>>>
>>>> If the integer was less than 24 bits you could use LA. Other than
>>>> that they seem to agree with you since S/390 has load and add
>>>> immediate with 16 bit values and relative branches. zSeries adds 32
>>>> bit immediate versions of most RX instructions.
>>>>
>>>> >Such instructions existed on earlier machines ...
>>>> >
>>>> >The base-displacement addressing model proved to be an impediment,
>>>> >tying up valuable general registers; instruction-relative addressing
>>>> >would have been far better.
>>>>
>>>> Relative addressing is fine for branches but less so for data.
>>>> zSeries added 20 bit displacements to most B+D instructions and a few
>>>> relative addressed data instructions.
>>>>
>>>> As far as I can tell, there were two motivations for based addressing
>>>> with 12 bit displacements which even in 1963 were pretty small. One
>>>> was to have an instruction format that worked reasonably well both on
>>>> small systems with 32K or 64K of memory and on large systems with a
>>>> megabyte or more. That worked well.
>>>
>>> No it didn't.
>>>
>>>> They knew that programs would need several base registers, but with
>>>> 16 registers there were enough.
>>>
>>> No there weren't. The XPL compiler has available only 3 registers for
>>> general arithmetic; the remainder are taken up with base addressing
>>> and other addressing, and there are still not enough.
>>>
>>>> The other was that they imagined that since all memory references
>>>> were base-relative, they could move programs and data around by
>>>> changing the base registsters and didn't need relocation hardware.
>>>
>>> Did they ever do that?
>>
>> It's sort of basic that a S/360 program can load at any address.
>
> Only if it uses Base-displacement addressing.
> But programs cannot be shifted around in memory while the program
> is being executed.
True, but they don't need to be shifted around in order to be used
by another address space at a different virtual address.
--
Dan Espen
|
|
|
|
Members
Search
Help
Register
Login
Home
