|
|
|
Re: John Titor was right? IBM 5100 [message #287028 is a reply to message #287010] |
Wed, 01 April 2015 09:02 |
jmfbahciv
Messages: 6173 Registered: March 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc wrote:
> On Tuesday, March 31, 2015 at 7:07:13 PM UTC-6, ethanpa...@gmail.com wrote:
>> Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,
>
> It's too late to stop them! Even if they can't get their hands on an IBM
5100,
> there's always Hercules. :)
How would one hack the ones which used mercury?
/BAH
|
|
|
Re: John Titor was right? IBM 5100 [message #287040 is a reply to message #287028] |
Wed, 01 April 2015 14:31 |
Quadibloc
Messages: 4399 Registered: June 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, April 1, 2015 at 7:02:10 AM UTC-6, jmfbahciv wrote:
> Quadibloc wrote:
>> On Tuesday, March 31, 2015 at 7:07:13 PM UTC-6, ethanpa...@gmail.com wrote:
>>> Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,
>> It's too late to stop them! Even if they can't get their hands on an IBM
> 5100,
>> there's always Hercules. :)
> How would one hack the ones which used mercury?
The Univac I used mercury delay lines, but I don't recall any big *IBM*
mainframes that used them. The IBM 701 used Williams tubes.
Hercules is a software program that runs on personal computers running Linux or
Windows that emulates System/360 computers. It is configurable to emulate all
the different versions of that architecture.
John Savard
|
|
|
Re: John Titor was right? IBM 5100 [message #287042 is a reply to message #287040] |
Wed, 01 April 2015 15:15 |
Anne & Lynn Wheel
Messages: 3156 Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> Hercules is a software program that runs on personal computers running Linux or
> Windows that emulates System/360 computers. It is configurable to emulate all
> the different versions of that architecture.
5100
http://en.wikipedia.org/wiki/IBM_5100
had 360 in "microcode"
http://en.wikipedia.org/wiki/IBM_5100#Emulator_in_microcode
somewhat the equivalent to hercules ... using (program all logic in
microcode)
http://en.wikipedia.org/wiki/IBM_PALM_processor
low-end and mid-range (real) ibm/370s emulated 370 instruction set in
vertical "microcode" (again very similar to hercules) ... tending to
avg. ten native instructions for every emulated 370 instruction ... aka
a 100KIP 370 needed a 1MIP native processor.
370/115 did about 80KIP 370 ... needing an 800kip native processor.
370/125 did about 120KIP 370 ... needing a 1.2MIP native processor.
late 70s there was an effort to move the large variety of different
native "microcode" & controller processors to (common) 801/risc
.... 4331->4361, 4341->4381, S38/S36->AS/400 ... lots of other processor (in
part because unique programming skill base had to be developed for each
processor)
http://www.garlic.com/~lynn/subtopic.html#801
however, for various reasons they floundered, and they reverted to
traditional custom ... as/400 had crash project to do a cisc
chip. However, a decade or so later, as/400 did migrate to 801/risc
(power/pc)
http://en.wikipedia.org/wiki/IBM_System_i
in the early 80s, when various of these 801/risc efforts were
floundering, there were 801/risc chip engineers deaparting the company
and showing up on risc projects at other companies.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
Re: John Titor was right? IBM 5100 [message #287055 is a reply to message #287040] |
Wed, 01 April 2015 20:52 |
Peter Flass
Messages: 8375 Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Wednesday, April 1, 2015 at 7:02:10 AM UTC-6, jmfbahciv wrote:
>> Quadibloc wrote:
>>> On Tuesday, March 31, 2015 at 7:07:13 PM UTC-6, ethanpa...@gmail.com wrote:
>>>> Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,
>
>>> It's too late to stop them! Even if they can't get their hands on an IBM
>> 5100,
>>> there's always Hercules. :)
>
>> How would one hack the ones which used mercury?
>
> The Univac I used mercury delay lines, but I don't recall any big *IBM*
> mainframes that used them. The IBM 701 used Williams tubes.
>
> Hercules is a software program that runs on personal computers running Linux or
> Windows that emulates System/360 computers. It is configurable to emulate all
> the different versions of that architecture.
>
all->most. It doesn't do the /20 or the /44, and I'm not sure about, e.g.
the vector instructions.
> John Savard
--
Pete
|
|
|
Re: John Titor was right? IBM 5100 [message #287066 is a reply to message #287042] |
Thu, 02 April 2015 05:20 |
Christian Corti
Messages: 33 Registered: September 2012
Karma: 0
|
Member |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> wrote:
> 5100
> http://en.wikipedia.org/wiki/IBM_5100
> had 360 in "microcode"
> http://en.wikipedia.org/wiki/IBM_5100#Emulator_in_microcode
This is wrong. The 5100/5110 has a normal microprogrammed processor
(called PALM) with a normal instruction set. Since IBM was too lazy to
program native interpreters for the PALM, they wrote simple machine
emulators (one for the S/360 and one for the S/3) in machine language,
not microcode. They thought that this would be easier...
These emulators are stored in ROMs (the so-called Language ROS). Since
only one ROS with machine code can be enabled at a time, the processor has
to switch between the Executable ROS (active during bring-up) and the
desired Language ROS. The emulator (executed by the PALM processor) then
executes its instruction (S/360 or S/3) from the APL or BASIC ROS; these
ROS' are not mapped into the PALM address space but instead, they are
accessed like an I/O device (with PUTB and GETB). The APL/BASIC
interpreter in turn runs the user program stored in RWS.
So that's the execution chain on the 51x0:
PALM --> machine emulator --> language interpreter --> user program
Of course, you can write your own machine programs for the 51x0. In
fact, all the utility programs delivered with the machine (either on
tape or on floppy) are machine programs. They are loaded with the LINK
(BASIC) or )LINK (APL) instruction from the interpreter at the RWS
address $0B00.
The DCP (Diagnostic Control Program) that can be accessed with HOLD
CMD-ATTN is also a PALM program residing in the Executable ROS.
> somewhat the equivalent to hercules ... using (program all logic in
> microcode)
> http://en.wikipedia.org/wiki/IBM_PALM_processor
PALM is an acronym for "Put All Logic in Microcode", not "Program ..."
This shows somehow that 1) Wikipedia can't be ultimatively trusted,
especially if there's no bibliography and 2) you just cite anything
without really knowing what you're writing about...
So here's an example from the S/360 emulator written in PALM assembler
(that I disassembled myself) that implements one variant of the AH
instruction:
; +------------------------------+
; | 4A | R1 | X2 | B2 | D2 |
; +----+----+----+----+----------+
; 0 8 12 16 20 31
;
; Add Halfword
;
; AH R1,D2(X2,B2)
; Get operands
06D2 0203 INC2 R2, R0
06D4 20BE JMP ($017C)
; Address of operand 2 within first 64kB?
06D6 C80B SNZ R8
06D8 A005 BRA $06E0 ; $06(R0)
; No, fetch operand 2 from ROS
06DA 0203 INC2 R2, R0
06DC 20AE JMP ($015C)
06DE A001 BRA $06E2 ; $02(R0)
; Operand 2 into R7/R8
06E0 D8D8 MOVE R8, (R13) ; Only halfword
06E2 2750 MOVE R7, $A0
; Sign extend Operand 2 to 32 bits
06E4 8180 LBI R1, #$80
06E6 C81F SNBSH R8, R1
06E8 F700 SUB R7, #$01
06EA A01F BRA $070C ; $20(R0)
And here's an example from the System/3 emulator:
; +----+----+-------+-------+
; | C8 | Q | Addr1 | Addr2 |
; +----+----+-------+-------+
; 0 8 16 32 47
;
; Jump to Addr2 if operand addressed by Addr1 is greater than Q
; Fetch operand
08FE 015E GETB R5, $1
0900 0C5D MLH R12, R5
0902 0004 NOP
0904 01CE GETB R12, $1
0906 63C8 MOVB R3, (R12) ; operand
0908 0004 NOP
090A 019E GETB R9, $1 ; Hi(Addr2)
090C C3E0 SLE R3, R14
090E A005 BRA $0916 ; greater
0910 0004 NOP
0912 01AE GETB R10, $1
0914 A009 BRA $0920 ; not greater
0916 01AE GETB R10, $1 ; Lo(Addr2)
0918 23C3 MOVE R3, $186
091A 4131 PUTB $1, (R3)++
091C 4138 PUTB $1, (R3) ; set new IP
091E 0004 NOP
0920 2082 JMP ($0104)
> 370/115 did about 80KIP 370 ... needing an 800kip native processor.
> 370/125 did about 120KIP 370 ... needing a 1.2MIP native processor.
[... long blob of unrelated information ...]
This is the answer to what question?
Christian
|
|
|
|
Re: John Titor was right? IBM 5100 [message #287078 is a reply to message #287066] |
Thu, 02 April 2015 13:58 |
Anne & Lynn Wheel
Messages: 3156 Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Christian Corti <use@reply.to> writes:
> This is wrong. The 5100/5110 has a normal microprogrammed processor
> (called PALM) with a normal instruction set. Since IBM was too lazy to
> program native interpreters for the PALM, they wrote simple machine
> emulators (one for the S/360 and one for the S/3) in machine language,
> not microcode. They thought that this would be easier...
re:
http://www.garlic.com/~lynn/2015c.html#42 John Titor was right? IBM 5100
My view is that it is semantics ... native processor programming used to
emulate another architecture tended to be called microcode. when I was
working on cp67 ... i use to refer to cp67 as the microcode of the
virtual machine
http://en.wikipedia.org/wiki/CP/CMS
I did some amount of work with the guy at PASC that did the 370/145 APL
assist "microcode" (and other native processor programming, especially
related to 370 emulation) ... I was at sister location on the other
coast in cambridge CSC ... some past posts
http://www.garlic.com/~lynn/subtopic.html#545tech
One such is that endicott roped me into helping with ECPS that would
come out for 138/148 (followon to 135/145). They had 6k bytes available
for ECPS (native) programming ... and wanted to choose the 6k bytes of
kernel instructions to move into native processor language (microcode)
.... aka moved from 370 to native on nearly byte-for-byte basis.
Two approaches were used to select the 6k bytes of instructions. One was
instruction hotspot ... a table of counters representing 32bytes of
kernel addresses was created in the 370/145 microcode ... and
(microcode) routine was added that periodically sampled the current
(kernel) instruction address and increment the corresponding address.
there was kernel modification that created time-stamps at entry and exit
of various routines and calculate the elapsed time since the previous
time-stamp. subpaths within routine could be calculated between points
that other routines were called. Old post with results from runs that
were used to select kernel codepaths for translation into "microcode":
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
the 370 emulator "microcode" had typical avg of ten native instructions
per 370 instructions ... so the 6k bytes of 370 instructions accounting
for 79.55% of time spent in kernel execution ... when moved into 6k
bytes of native instructions ... it ran ten times faster.
the "vertical" native programming instruction of low-end & mid-range
microprocessors looked very much like machine programming. The high-end
370s were horizontal microprogramming ... which was more like lots of
bits that activated/started various hardware operations ... that could
run in parallel. Instead of being characterized as avg. number of
(vertical) native instructions per 370 instruction ... they were
characterized as avg. machine cycles per 370 instruction. The 370/165
was 2.1 machine cycles per 370 instruction ... but was improved for
370/168 to 1.6 machine cycles per 370 instruction ... and then improved
to one machine cycle per 370 instruction for 3033.
I've mentioned before that during FS period, internal 370 efforts were
being killed off and the lack of 370 products during this period allowed
clone processors to gain market foothold
http://www.garlic.com/~lynn/submain.html#futuresys
when FS imploded ... there was mad rush to get products back into the
370 pipeline and 3033 and 3081 were kicked off in paralle. 3033 started
out Q&D remap of 168 logic to 20% faster chips ... however tweaks done
along the way (like reducing avg. machine cycles per 370 instruction)
got 3033 up to 1.5 times 168. this has discussion of FS and how poorly
the 3033 & 3081 compared to clone competition:
http://www.jfsowa.com/computer/memo125.htm
The 3033 started doing minor microcode feature tweaks with the kernel
software not running unless those features were available (by
comparison, the ECPS kernel code dynamically determined whether ECPS was
available or not and adapt accordingly, running on machines with or w/o
the microcode tweaks). The 3033 wanted to offer something similar to
ECPS on their machine ... but since the 3033 was already running at one
machine cycler per 370 instruction ... it was difficult to show any
performance improvement using that approach (and because of various
reasons could even run slower).
The high-end clone processor competition reacted to this frequent
microcode feature changes/tweaks with "macro-code" ... approximately a
special state for 370-like instructions ... which was much easier to
change/program than native horizontal microcode. Later this was then
used to implement a special hardware hypervisor (basically a subset of
virtual machine functions). It took significant time & effort for 3090
to react to this competition with PR/SM ... since it all had to be done
(in the much more difficult) native horizontal "microcode".
disclaimer: I had transferred from CSC to SJR in san jose and was
regular at monthly baybunch meetings. I did a series of presentations at
baybunch on how ECPS was done. the people in the audience that were
working on hypervisor with macrocode in the audience were asking loads
of questions (hypervisor hadn't been announced yet).
some past posts mentioning PR/SM and/or macrocode
http://www.garlic.com/~lynn/2013.html#3 Is Microsoft becoming folklore?
http://www.garlic.com/~lynn/2013.html#58 Was MVS/SE designed to confound Amdahl?
http://www.garlic.com/~lynn/2013.html#69 What is a Mainframe?
http://www.garlic.com/~lynn/2013f.html#68 Linear search vs. Binary search
http://www.garlic.com/~lynn/2013i.html#36 The Subroutine Call
http://www.garlic.com/~lynn/2013l.html#27 World's worst programming environment?
http://www.garlic.com/~lynn/2013n.html#46 'Free Unix!': The world-changing proclamation made30yearsagotoday
http://www.garlic.com/~lynn/2013n.html#62 'Free Unix!': The world-changing proclamation made30yearsagotoday
http://www.garlic.com/~lynn/2014b.html#80 CPU time
http://www.garlic.com/~lynn/2014b.html#82 CPU time
http://www.garlic.com/~lynn/2014d.html#17 Write Inhibit
http://www.garlic.com/~lynn/2014d.html#20 Write Inhibit
http://www.garlic.com/~lynn/2014e.html#39 Before the Internet: The golden age of online services
http://www.garlic.com/~lynn/2014f.html#78 Over in the Mainframe Experts Network LinkedIn group
http://www.garlic.com/~lynn/2014i.html#90 IBM Programmer Aptitude Test
http://www.garlic.com/~lynn/2014j.html#10 R.I.P. PDP-10?
http://www.garlic.com/~lynn/2014j.html#19 DG Nova 1200 as console
http://www.garlic.com/~lynn/2014j.html#100 No Internet. No Microsoft Windows. No iPods. This Is What Tech Was Like In 1984
http://www.garlic.com/~lynn/2014m.html#161 Slushware
http://www.garlic.com/~lynn/2015.html#85 a bit of hope? What was old is new again
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
Re: John Titor was right? IBM 5100 [message #287084 is a reply to message #287066] |
Thu, 02 April 2015 18:08 |
Quadibloc
Messages: 4399 Registered: June 2012
Karma: 0
|
Senior Member |
|
|
Ah, yes; I found an earlier post of yours in a thread talking about the 5100 ROMs.
Since the 5100 had a copy of APLSV there - and IBM only recently consented to the
publication of the APL/360 source as part of the release of MTS - I'd suspect
that they still regard at least *that* piece of 5100 code as still of commercial
value.
This is a pity, of course; I'd love to be able to download a 5100 emulator, but I think it unavoidable.
John Savard
|
|
|
Re: John Titor was right? IBM 5100 [message #287085 is a reply to message #287084] |
Thu, 02 April 2015 18:59 |
Anne & Lynn Wheel
Messages: 3156 Registered: January 2012
Karma: 0
|
Senior Member |
|
|
Quadibloc <jsavard@ecn.ab.ca> writes:
> Ah, yes; I found an earlier post of yours in a thread talking about
> the 5100 ROMs.
>
> Since the 5100 had a copy of APLSV there - and IBM only recently
> consented to the publication of the APL/360 source as part of the
> release of MTS - I'd suspect that they still regard at least *that*
> piece of 5100 code as still of commercial value.
>
> This is a pity, of course; I'd love to be able to download a 5100
> emulator, but I think it unavoidable.
re:
http://www.garlic.com/~lynn/2015c.html#42 John Titor was right? IBM 5100
http://www.garlic.com/~lynn/2015c.html#44 John Titor was right? IBM 5100
note that CSC had done a port of apl\360 to cp67/cms as cms\apl. csc
took a lot of heat over it because it provided straight-forward API to
system services ... like doing file i/o.
since cms\apl was single user (relying on cp67 for multitasking) all the
apl\360 multitasking & swapping could be removed. However there was a
major issue with apl\360 storage management & garbage
collection. apl\360 would allocated new piece of (unallocated) storage
for every assignment ... and then when storage was exhausted it would
garbage collect all in-use storage into contiguous locations. For
apl\360 with 16kbyte (or 32kbyte) workspace swapped as integral unit
.... it wasn't bad ... but cms\apl opened workspace size to full virtual
memory area in cp67 demand paged environment. The standard apl\360
storage management guarenteed that any apl application would page thrash
in cp67/cms environment ... repeatedly touching every location/changing
in virtual memory. This had to be reworked for cms\apl to be much more
virtual memory demand paged friendly.
PASC then did apl\cms for vm370/cms with the aplsv shared variable
semantics for accessing system services (like file i/o) ... as well
as doing the 370/145 apl microcode assist.
by this time the internal hone US datacenters had consolidated in bldg
across the back parking lot from PASC (trivia, the bldg has another
resident now, but when facebook 1st moved to the area, it was a new 1601
bldg right next door to the old HONE datacenter 1501 bldg).
The internal HONE originated ... some past posts
http://www.garlic.com/~lynn/subtopic.html#hone
after the 23jun69 unbundling announcement ... some past posts
http://www.garlic.com/~lynn/subtopic.html#unbundling
to provide "hands-on" operating system practice for branch office SEs
.... running in CP67 virtual machines. However, HONE also started
delivering APL-based sales&marketing support applications (originally on
cms\apl and then later apl\cms) which came to quickly dominate all HONE
activity. In the late 70s, the consolidate US HONE datacenter (across
the back parking lot from PASC) was the largest single-system-image
cluster of loosely-coupled, 168 SMP multiprocessors (and also the
largest user of APL ... especially as HONE-clones started to proliferate
around the world).
the (PASC) 370/145 APL microcode assist tended to make pure APL code run
as fast on 370/145 as (non-assist) APL code ran on 370/168. The HONE
issue was that the online sales&marketing workload, while APL-based was
also large virtual memory & heavy I/O ... workload needing the rest of
the 370/168 capability (not available from 370/145). As a result there
were various other kinds of efforts worked on to try and speed up the
HONE APL applications.
disclaimer: one of my hobbies was providing enhanced operating systems
for internal datacenters ... and HONE was one of my first & long time
customers. as relatively new-hire out of school ... my first overseas
business trips was being asked to go along for HONE-clone overseas
installations.
--
virtualization experience starting Jan1968, online at home since Mar1970
|
|
|
|
|
|