Re: My Migrations: PC architecture
- From: Robert <no@xxxxxx>
- Date: Mon, 06 Oct 2008 22:25:18 -0500
On Sun, 5 Oct 2008 12:07:16 -0700 (PDT), Richard <riplin@xxxxxxxxxxxx> wrote:
On Oct 4, 1:13 pm, Robert <n...@xxxxxx> wrote:
On Fri, 3 Oct 2008 10:37:29 -0500, "tlmfru" <la...@xxxxxxx> wrote:
Pete Dashwood <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6kl125F8bkpgU1@xxxxxxxxxxxxxxxxxxxxx
Running the IBM architecture on a PC...
I think you could definitely emulate the architecture on a modern PC, butisn't.
why would you want to? Are you suggesting that the BAL architecure is
superior to the Intel or Motorola architectures? I can assure you, it
It was brilliant for its time, but that time is long gone. It exists today
because it is buried in legacy, not because it is the best architecture.
A further thought: if IBM had actually used the BAL instruction set for
their PC, or a subset of it, I'd wager that we would never have heard of
"expanded memory", "extended memory", "upper and lower memory blocks", the
unaddressable top 64K of memory - all the things that could be inserted into
the dictionary replacing the word "kludge".
IBM doesn't learn from its mistakes. The 360 was a 32 bit machine that, for no good
reason, used only 24 bits to address memory, thus putting a 16M limit on the size of
memory.
You are wrong, there were many _very_good_ reasons (at least as good
as Doc's), such as 'no one will ever need more than ...' and saving
one quarter of the circuit boards in the address translator, and using
the bits for another task.
They used one bit for problem/supervisor state and four bits for memory protection key,
thereby limiting the number of running programs to 15 (no one will ever need more). That
was in the Program Status Word (PSW), a single register. The upper eight bits were wasted
in other registers and pointers in memory.
Thirty years after the limit was removed (with XA), mainframers are STILL dealing with
above-the-line/below-the-line issues.
The Intel 808x was a 16 bit machine capable of a 28 bit memory address: 16 bit segment and
12 bit offset. It could have handled 256M of memory, but Intel decided, for no good
reason, to limit it to 1M.
It would have required millions (ok probably thousands) more
transistors in the chip to use a 28 bit address. It also would have
poor granularity with most of the memory address space being wasted.
They tried it with 286 protected mode but that was a complete failure
because it would run out of registers to hold segment addresses.
Fragmentation is not important on a virtual memory machine like the 286. Unused portions
of the 1TB virtual address space (per process) were not mapped to real memory.
Those device drivers were soon replaced by more capable
software ones, but the address space remained lost.
Not true at all for the 8088/8086 based machines. The IBM PC used the
address space for memory mapped screens as well as the BIOS and that
area was always addressable.
It used 64K for memory mapped screens. The other 320K was wasted. 128K, C000 and D000,
wasn't even used, it was reserved for unspecified add-ons, which were on their own to
resolve conflicts.
There was no good reason for the screen or anything else to be at fixed locations. The
BIOS could have allocated segments dynamically.
Both limits were mistakes that required extraordinary effort to overcome.
No. What was a mistake was trying to use a toy machine that was mostly
obsolete when it was introduced (the IBM PC) and a toy operating
system that was a poorly implemented clone (or copy) of a six year old
system (CP/M) that had been built with the limitations of 64Kb in
mind.
The design team, headed by Don Estridge, had one year to get the PC to market. As an Entry
Systems Division (ESD) outpost in Boca Raton Fl, they had little support from or influence
over mainstream IBM. They decided to go with components readily available from mostly
non-IBM sources. Think of them as a company started in a garage.
After IBM saw how successful the PC was, it pulled the PC back into the corporate fold,
which produced flops including the PC Jr (make it into toy), 3270 PC (make it into a
terminal) and PS2 (make it proprietary).
The poor implementation of the BIOS and of MS-DOS meant that basic
operations, such as screen i-o were very slow and lacked
functionality. To get reasonable speed and facility (such as colour)
it was necessary to bit-bang the hardware (eg direct screen writes).
My device drivers offered a choice between direct, BIOS and DOS screen writes.
BIOS wasn't objectionably slow; DOS was. The driver filtered out unnecessary writes of
characters that had not changed.
Especially troublesome was displaying graphics on a monochrome adaptor by Hercules and
clones. Because card makers never produced a BIOS (I did), nearly all software support for
graphics was for CGA only. To show it on a mono screen, I had to change its aspect ratio.
It was a challenge to do that with animated games fast enough to avoid ghosting and
noticable lag.
Programmers used segment arithmetic on pointers to access data faster
and this led to code that was incompatible with better processors and
prevented adoption of 286 protected mode and OS/2.
It was never necessary to do arithmetic on segment addresses. I never did it, don't know
why anyone would.
Intel had made a chip that was 'the best 8bit micro',
No, it was clearly a 16 bit CPU.
IBM had made a
machine a few percent better than the Apple ][ (eg more memory, faster
CPU, 160Kb vs 120Kb disks) to stop intrusion into their space and as a
terminal - serial and 3740.
I don't think IBM corporate had a clear vision of the PC's role. Some saw it as a toy,
some as competition for their low end 52xx single user machines, some as a smart terminal.
I saw it as a tiny mainframe.
The mistake was by the programmers who, impressed by the brand name,
thought they could use these for real work instead of using properly
designed machines running useful operating systems and, since the mid
70s, doing it with networking, shared drives and multi-tasking.
IN 1984 I ran a drag race between a PC with 30M hard drive versus a 4361 (small
mainframe), running the same Cobol program doing 'typical' batch processing VSAM
operations. The PC won.
I then proceeded to write a multi-tasking application under MSDOS, with cooperative task
switching in the application. Each PC ran four tasks; each task handled two modems -- one
data and one voice/DTMF. We ran ten PCs talking to up to 40 users.
Also, we'd have had
multiprogramming a lot sooner, and would have heard less of memory leaks.
(This isn't due to any intrinsic superiority of the BAL set. It's just that
all the O/S progamming experience that had been done with it would certainly
have been drawn upon).
OS/2 was obviously written by MVS guys, because its internal structures used the same
terminology as MVS internals. Its failure disproves the assertion that mainframe expertise
would have prevailed.
Actually OS/2 was originally written by Microsoft. Granted it was to
IBMs spec. MS-DOS 4.0 (not to be confused with the later 4.01) was
designed by MS and was a failure. IBM speced MS-DOS 5 (not the be
confused with the later MS-DOS 5) to be a 286 based OS and it was
later named OS/2. When Microsoft had stolen all the useful bits out
of OS/2's design and incorporated them into Windows-286 and Windows
extended mode (3.0), it spat the dummy and IBM had to rescue the code
it had paid MS to write.
OS/2 is a good example of infighting between IBM divisions. IBM's own PC marketing
division was selling PCs bundled with Windows. They, along with Microsoft, targeted home
users; OS/2 developers were trying to replace MVS; other IBMers were pushing Linux.
.
- Follow-Ups:
- Re: My Migrations: PC architecture
- From: Howard Brazee
- Re: My Migrations: PC architecture
- From: Richard
- Re: My Migrations: PC architecture
- References:
- Re: My Migrations
- From: Pete Dashwood
- Re: My Migrations
- From: tlmfru
- Re: My Migrations
- From: Pete Dashwood
- Re: My Migrations: PC architecture
- From: tlmfru
- Re: My Migrations: PC architecture
- From: Robert
- Re: My Migrations: PC architecture
- From: Richard
- Re: My Migrations
- Prev by Date: Re: date processing in z/OS
- Next by Date: Re: My Migrations: PC architecture
- Previous by thread: Re: My Migrations: PC architecture
- Next by thread: Re: My Migrations: PC architecture
- Index(es):
Relevant Pages
|