Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Re: John Titor was right? IBM 5100
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: John Titor was right? IBM 5100 [message #287003] Tue, 31 March 2015 21:07 Go to next message
Anonymous
Karma:
Originally posted by: ethanpalmer765

Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,
Re: John Titor was right? IBM 5100 [message #287010 is a reply to message #287003] Wed, 01 April 2015 01:13 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
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. :)

John Savard
Re: John Titor was right? IBM 5100 [message #287013 is a reply to message #287003] Wed, 01 April 2015 02:30 Go to previous messageGo to next message
Bob Martin is currently offline  Bob Martin
Messages: 157
Registered: August 2012
Karma: 0
Senior Member
in 644365 20150401 020712 ethanpalmer765@gmail.com wrote:
> Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,

IBM 5100 wasn't a mainframe - far from it.
Re: John Titor was right? IBM 5100 [message #287028 is a reply to message #287010] Wed, 01 April 2015 09:02 Go to previous messageGo to next message
jmfbahciv is currently offline  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 Go to previous messageGo to next message
Quadibloc is currently offline  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 Go to previous messageGo to next message
Anne & Lynn Wheel is currently offline  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 Go to previous messageGo to next message
Peter Flass is currently offline  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 Go to previous messageGo to next message
Christian Corti is currently offline  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 #287069 is a reply to message #287055] Wed, 01 April 2015 23:52 Go to previous messageGo to next message
Shmuel (Seymour J.) M is currently offline  Shmuel (Seymour J.) M
Messages: 3286
Registered: July 2012
Karma: 0
Senior Member
In
<829078131449628608.584049peter_flass-yahoo.com@news.eternal-september.org>,
on 04/02/2015
at 12:52 AM, Peter Flass <peter_flass@yahoo.com> said:

> all->most. It doesn't do the /20 or the /44,

Those deviate from the S/360 architecture.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
Re: John Titor was right? IBM 5100 [message #287078 is a reply to message #287066] Thu, 02 April 2015 13:58 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; 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 Go to previous messageGo to next message
Quadibloc is currently offline  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 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; 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
Re: John Titor was right? IBM 5100 [message #287112 is a reply to message #287084] Fri, 03 April 2015 04:59 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
I've visited your fascinating web site at

http://computermuseum.informatik.uni-stuttgart.de/dev/ibm_51 10/technik/en/

and I find some of my earlier comments are out of date.

John Savard
Re: John Titor was right? IBM 5100 [message #363508 is a reply to message #287066] Thu, 15 February 2018 02:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: thecanadianwalker

WRONG!
Re: John Titor was right? IBM 5100 [message #400160 is a reply to message #287003] Thu, 17 September 2020 11:27 Go to previous message
Anonymous
Karma:
Originally posted by: Useless trash

On Wednesday, April 1, 2015 at 3:07:13 PM UTC+14, ethanpa...@gmail.com wrote:
> Oh my god now hackers are going to hack big IBM mainframes !!!!!!,,
el psy congroo
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Next FCUG meeting - Sunday, September 20 (cancelled)
Next Topic: Re: John Titor was right? IBM 5100
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 14:57:57 EDT 2024

Total time taken to generate the page: 0.00332 seconds