Virtual memory and memory protection

Larry Elmore wrote:
> robertwessel2@yahoo.com wrote:
> > Terje Mathisen wrote:
> >
> >>The original WordStar was supposedly ported (i.e. translated) this way.
> >
> >
> >
> > A fair number of CP/M programs were ported to MS-DOS that way.  Most
> > 8080 instructions mapped exactly to one or two 8086 instructions, so
> > performance was not bad.
>
> What I remember reading at the time was that performance "not bad" in
> the sense that the converters worked and the programs ran, but that they
> were poor performers compared to the same app written specifically for
> 8086 (which is about what I would expect).  Is this wrong?


That's about right.  As I recall, converted programs mostly ran rather
faster on a 4.77MHz 8088 than they did on a 2Mhz 8080.  A native
rewrite would usually speed things up significantly.

robertwessel2@yahoo.com wrote:

> Larry Elmore wrote:

(snip regarding 8080 to 8086 translation)

>>What I remember reading at the time was that performance "not bad" in
>>the sense that the converters worked and the programs ran, but that they
>>were poor performers compared to the same app written specifically for
>>8086 (which is about what I would expect).  Is this wrong?

> That's about right.  As I recall, converted programs mostly ran rather
> faster on a 4.77MHz 8088 than they did on a 2Mhz 8080.  A native
> rewrite would usually speed things up significantly.

If, for example, the 8080 code was doing 16 bit arithmetic 8 bits
at a time then converting to 16 bit 8086 code should be much faster.

If it really did only 8 bit stuff it might not make a big difference.

-- glen

Larry Elmore wrote:

> robertwessel2@yahoo.com wrote:
> 
>>Terje Mathisen wrote:
>>
>>
>>>The original WordStar was supposedly ported (i.e. translated) this way.
>>
>>A fair number of CP/M programs were ported to MS-DOS that way.  Most
>>8080 instructions mapped exactly to one or two 8086 instructions, so
>>performance was not bad.
> 
> What I remember reading at the time was that performance "not bad" in
> the sense that the converters worked and the programs ran, but that they
> were poor performers compared to the same app written specifically for
> 8086 (which is about what I would expect).  Is this wrong?

Almost certainly right:

Doing the machine translation stuff would result in an accumulator-based
program, with an awful lot of memory operations for stuff that could
easily have fit in the other registers.

Since each byte touched on an 8088 (both data and CODE!) would take a
four-cycle bus operation, the speed of code on this cpu was _very_
dependent upon writing very tight code, with the minimum number of
load/store operations.

My wild guess would be that you'd get a 2X to 4X speedup by re-writing
your asm code for the new cpu.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

robertwessel2@yahoo.com wrote:
> Terje Mathisen wrote:
> 
>>The original WordStar was supposedly ported (i.e. translated) this way.
> 
> 
> 
> A fair number of CP/M programs were ported to MS-DOS that way.  Most
> 8080 instructions mapped exactly to one or two 8086 instructions, so
> performance was not bad.
> 
> MS-DOS itself also had a fair bit of campatibility built in (function
> numbers and semantics for much of the early the INT 21h API, for
> example).  There was (is?) even a far call to the MS-DOS kernel
> embedded in location +5 of the PSP, which would accept the function
> number in CL (this matches the CP/M OS calling convention - "call 5").

Bear in mind that "MS-DOS" started out as Seattle Computer Products' 
86-DOS which was explicitly designed to permit easy porting of CP/M 
assembly code. It also included a utility for translating Zilog Z-80 asm 
source into SCP's 8086 assembler, along with "readcpm.com" for reading 
CP/M formatted floppies (86-DOS systems typically used 8 inch floppies 
with a 12 bit FAT filesystem).

The first versions of "Vedit" for 86-DOS and MS-DOS appeared to have 
been translations - Vedit came with macro's to do much of the 
thranslation work. Some of the early reports on the IBM PC's rom-basic 
commented that it looked like much of the code was simply translated 
rather than written specifically for the 8086/88.

The 86-DOS user interface was significantly different than CP/M, using 
"A:" instead of "A>", "copy" instead of "pip" and "era(se)" instead of 
"del(ete)". IBM apparently wanted the PC-DOS user interface to be a bit 
CP/M like.

- erik

Erik Magnuson wrote:

(snip)

> The first versions of "Vedit" for 86-DOS and MS-DOS appeared to have 
> been translations - Vedit came with macro's to do much of the 
> thranslation work. Some of the early reports on the IBM PC's rom-basic 
> commented that it looked like much of the code was simply translated 
> rather than written specifically for the 8086/88.

I was told once that the TRS-80 Color Computer (6809 based) was the 
predecessor to IBM ROM Basic.  I do know that the commands and 
statements are very similar.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Erik Magnuson wrote:
> 
> (snip)
> 
> > The first versions of "Vedit" for 86-DOS and MS-DOS appeared to have been
> > translations - Vedit came with macro's to do much of the thranslation
> > work. Some of the early reports on the IBM PC's rom-basic commented that
> > it looked like much of the code was simply translated rather than written
> > specifically for the 8086/88.
> 
> I was told once that the TRS-80 Color Computer (6809 based) was the
> predecessor to IBM ROM Basic.  I do know that the commands and statements
> are very similar.

Well they were both done by Microsoft. Rather different instruction sets
(6809 vs 8086) to contend with, though.

-- 
David Gay
dgay@acm.org

"Terje Mathisen" <terje.mathisen@hda.hydro.com> wrote in message
news:deuf14$806$1@osl016lin.hda.hydro.com...

> Oh, there's plenty more left-over CPM baggage in Dos (particularly V1.0):
>
> The stack of all programs were initialialized with a zero work, and
> offset 0 of the Program Segment Prefix (PSP), where your offset 5 had
> the OS call, has a shart-hand 'Program Exit' call, in the form of 0xCD
> 0x20, i.e. INT 20h.
>
> Offset 0x5C (afair) contained a preparsed version of the first input
> parameter, assuming it fit the [D:]FILENAME.EXT pattern, offset 0x80 was
> the start of the 128-byte program input field etc.

Not to mention file access through file control blocks instead of handles.
mind you: FCB's were supported up to Windows 95!

I still keep an old laptop handy with Win95, to support an old Pascal MT+
compiler that runs in a CP/M emulator in DOS. The emulator uses FCB's....

Meindert

Meindert Sprang wrote:
> Not to mention file access through file control blocks instead of handles.
> mind you: FCB's were supported up to Windows 95!
>
> I still keep an old laptop handy with Win95, to support an old Pascal MT+
> compiler that runs in a CP/M emulator in DOS. The emulator uses FCB's....


FCBs are still supported in the DOS box of WinXP.

<robertwessel2@yahoo.com> wrote in message
news:1125354181.434749.276400@z14g2000cwz.googlegroups.com...
>
> Meindert Sprang wrote:
> > Not to mention file access through file control blocks instead of
handles.
> > mind you: FCB's were supported up to Windows 95!
> >
> > I still keep an old laptop handy with Win95, to support an old Pascal
MT+
> > compiler that runs in a CP/M emulator in DOS. The emulator uses
FCB's....
>
>
> FCBs are still supported in the DOS box of WinXP.

Ah, didn't know that. All experienced years ago when I transitioned from 95
to NT that they were gone. So I assumed that was the end of it.

Meindert