[TUHS] Harvard and Von Neumann Architectures and Unix

[TUHS] Harvard and Von Neumann Architectures and Unix

[Noel Chiappa]

    > From: Doug McIlroy

    > But if that had been in D space, it couldn't have been executed.

Along those lines, I was wondering about modern OS's, which I gather for
security reasons prevent execution of data, and prevent writing to code.

Programs which emit these little 'custom code fragments' (I prefer that term,
since they aren't really 'self-modifying code' - which I define as 'a program
which _changes_ _existing_ instructions) must have some way of having a chunk
of memory into which they can write, but which can also be executed.


    > Where is the boundary between changing one instruction and changing them
    > all? Or is this boundary a figment of imagination?

Well, the exec() call only overwrites existing instruction memory because of
the semantics of process address space in Unix - there's only one, so it has
to be over-written. An OS operating in a large segmented single-level memory
could implement an exec() as a jump....

BTW, note that although exec() in a single address-space OS is conventionally
something the OS does, this functionality _could_ be moved into the user
space, provided the right address space primitives were provided by the OS,
e.g. 'expand instruction space'. So the exec() code in user space would i)
find the executable, ii) see how much of each kind of memory it needs, iii)
get the OS to give it a block of memory/address space where the exec() code
can live while it's reading in the new code, iv) move itself there, v) use
standard read() calls to read the new image in, and then vi) jump to it.

Yes, it's probably simpler to implement it in the OS, but if one's goal is to
minimize the functionality in the kernel...

	 Noel

[TUHS] Harvard and Von Neumann Architectures and Unix

[Larry McVoy]

On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
>     > From: Doug McIlroy
> 
>     > But if that had been in D space, it couldn't have been executed.
> 
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.
> 
> Programs which emit these little 'custom code fragments' (I prefer that term,
> since they aren't really 'self-modifying code' - which I define as 'a program
> which _changes_ _existing_ instructions) must have some way of having a chunk
> of memory into which they can write, but which can also be executed.

Isn't that how dtrace works?

[TUHS] Harvard and Von Neumann Architectures and Unix

[Clem Cole]

SPICE2 does the same sort of thing (in semi-portable Fortran-IV)

On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that
> term,
> > since they aren't really 'self-modifying code' - which I define as 'a
> program
> > which _changes_ _existing_ instructions) must have some way of having a
> chunk
> > of memory into which they can write, but which can also be executed.
>
> Isn't that how dtrace works?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/26a802f2/attachment.html>

[TUHS] Harvard and Von Neumann Architectures and Unix

[Lawrence Stewart]

> On 2017, Nov 27, at 12:08 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> SPICE2 does the same sort of thing (in semi-portable Fortran-IV)
> 
> On Mon, Nov 27, 2017 at 11:50 AM, Larry McVoy <lm at mcvoy.com <mailto:lm at mcvoy.com>> wrote:
> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that term,
> > since they aren't really 'self-modifying code' - which I define as 'a program
> > which _changes_ _existing_ instructions) must have some way of having a chunk
> > of memory into which they can write, but which can also be executed.
> 
> Isn't that how dtrace works?
> 

In POSIX systems, the mprotect(2) syscall can set execute permissions.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/bca34ff5/attachment-0001.html>

[TUHS] Harvard and Von Neumann Architectures and Unix

[Lars Brinkhoff]

Lawrence Stewart wrote:
> Noel Chiappa wrote:
>> Programs which emit these little 'custom code fragments' (I prefer
>> that term, since they aren't really 'self-modifying code' - which I
>> define as 'a program which _changes_ _existing_ instructions) must
>> have some way of having a chunk of memory into which they can write,
>> but which can also be executed.
>
> In POSIX systems, the mprotect(2) syscall can set execute permissions.

Or if a statically allocated space is ok, just set your pages to rwx in
the executable image file.

[TUHS] Harvard and Von Neumann Architectures and Unix

[Warner Losh]

On Mon, Nov 27, 2017 at 9:50 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 27, 2017 at 11:11:41AM -0500, Noel Chiappa wrote:
> >     > From: Doug McIlroy
> >
> >     > But if that had been in D space, it couldn't have been executed.
> >
> > Along those lines, I was wondering about modern OS's, which I gather for
> > security reasons prevent execution of data, and prevent writing to code.
> >
> > Programs which emit these little 'custom code fragments' (I prefer that
> term,
> > since they aren't really 'self-modifying code' - which I define as 'a
> program
> > which _changes_ _existing_ instructions) must have some way of having a
> chunk
> > of memory into which they can write, but which can also be executed.
>
> Isn't that how dtrace works?
>

That's not self modifying code. I've written some self-modifying code (I
was young, it was sexy, I thought), and it's all about rewriting your own
instruction stream. And doing so based on data you get so far. Not every
modification of a text page is self-modifying code.

dtrace, and every debugger that doesn't have hardware assist debug
registers (or overflows them) modifies the text pages to allow breakpoints,
watchpoints, tracepoints and the like to work. Even the OS creates code to
run at runtime. The signal trampoline that's used to return from a signal
handler in BSD is a small bit of code the OS fills in bits of out of a
template. It's one of the things that slowed adoption of turning off the X
bit for stack pages in response to many of the buffer overflow attacks.

On modern architectures, a fair amount of PTE and/or cache dancing needs to
happen to make this stuff work sometimes. Some processors make this easy
with dual mappings, others are... what's the right word... tedious.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171127/59598dd0/attachment.html>

[TUHS] Harvard and Von Neumann Architectures and Unix

[Paul Winalski]

On-chip, all modern x86 processors operate entirely out of a hierarchy
of caches, and there are separate caches for instructions and data.
Main memory is really merely the first in the "slow access storage"
hierarchy.  So in that sense I suppose one could consider modern CPUs
to be Harvard architecture.

-Palu W.

[TUHS] Harvard and Von Neumann Architectures and Unix

[Ian Zimmerman]

On 2017-11-27 11:11, Noel Chiappa wrote:

> Programs which emit these little 'custom code fragments' (I prefer
> that term, since they aren't really 'self-modifying code' - which I
> define as 'a program which _changes_ _existing_ instructions) must
> have some way of having a chunk of memory into which they can write,
> but which can also be executed.

As the writable/executable bits are usually in the page table (on linear
paged architectures which currently dominate the field), I imagine the
answer is dual page mappings.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet, fetch the TXT record for the domain.

[TUHS] Harvard and Von Neumann Architectures and Unix

[Tim Bradshaw]

On 27 Nov 2017, at 16:11, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.
> 
> Programs which emit these little 'custom code fragments' (I prefer that term,
> since they aren't really 'self-modifying code' - which I define as 'a program
> which _changes_ _existing_ instructions) must have some way of having a chunk
> of memory into which they can write, but which can also be executed.

I think, however this is done, it must be relatively tractable, because Lisp systems with native-code compilers work fine on modern OSs, and they do very much more than generate small code fragments.

--tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171128/e5e0b054/attachment.html>

[TUHS] Harvard and Von Neumann Architectures and Unix

[Paul Winalski]

On 27 Nov 2017, at 16:11, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>
> Along those lines, I was wondering about modern OS's, which I gather for
> security reasons prevent execution of data, and prevent writing to code.

They do by default, at least, in that modern linkers create executable
images where the executable program segments are read-only and
read/write segments (including the stack) are not executable.  But
modern OSes have system services for changing page protection, so an
application such as an interpreter or JIT can compose code and then
change the page protection to make it executable.

-Paul W.

[TUHS] Harvard and Von Neumann Architectures and Unix

[Noel Chiappa]

    > From: Larry McVoy

    >> they aren't really 'self-modifying code' - which I define as 'a program
    >> which _changes_ _existing_ instructions

    > Isn't that how dtrace works?

I'm not familiar with dtrace(), but if it modifies some other routine's code,
then it would not be "self" modifying, right?


Oh, another category, sort of like biological viruses (which are in a grey
zone between 'alive' and not): the PDP-11 paper tape bootstrap:

  http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/bootloader.mac

in which the program's own code _is_ modified - but not by program
instructions, but by data on the paper tape it is reading in. It's
entertainingly convoluted (the copy above should be well-enough commented to
make it pretty easy to understand what's going on).

     Noel

[TUHS] Harvard and Von Neumann Architectures and Unix

[Dave Horsfall]

On Mon, 27 Nov 2017, Noel Chiappa wrote:

> I'm not familiar with dtrace(), but if it modifies some other routine's 
> code, then it would not be "self" modifying, right?

No more than the IBM-360's "EX" instruction was self-modifying, I guess.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Harvard and Von Neumann Architectures and Unix

[Doug McIlroy]

From the discussion of self-modifying code:

>> Optimal code for bitblt (raster block transfers) in the Blit
>
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> > former is what I was thinking of.
> 
It built small custom fragments of code. But if that had been in D
space, it couldn't have been executed. 
 
>> Surely JIT compiling must count as self-modifying code.
>
> If it does, then my computer just runs one program from when I turn it
> on.  It switches memory formats and then is forever extending itself and
> throwing chunks away.

Exactly. That is the essence of stored-program computers. The exec
system call is self-modification with a vengeance.

Fill memory-and-execute is the grandest coercion I know. What is
data one instant is code the next.

It's all a matter of viewpoint and scale. Where is the boundary
between changing one instruction and changing them all? Or is
this boundary a figment of imagination?

Doug

[TUHS] Harvard and Von Neumann Architectures and Unix

[Noel Chiappa]

    > From: Doug McIlroy

    > Optimal code for bitblt (raster block transfers) in the Blit

Interesting case. I'm not familiar with BitBLT codes, do they actually modify
the existing program, or rather do they build small custom ones? Only the
former is what I was thinking of.

       Noel

[TUHS] Harvard and Von Neumann Architectures and Unix

[Lawrence Stewart]

Slightly related to Unix I suppose:  Linux kernels generate page table walking code from a little assembler inside the kernel that is run at boot time.  

> On 2017, Nov 25, at 9:24 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Doug McIlroy
> 
>> Optimal code for bitblt (raster block transfers) in the Blit
> 
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.
> 
>       Noel
> 

[TUHS] Harvard and Von Neumann Architectures and Unix

[Lars Brinkhoff]

Noel Chiappa wrote;
> Doug McIlroy wrote:
> > Optimal code for bitblt (raster block transfers) in the Blit
> Interesting case. I'm not familiar with BitBLT codes, do they actually
> modify the existing program, or rather do they build small custom
> ones?

They could modify existing programs using a blitter. :-)

This has actually been done, but for generating software synthesizer
code.  The blitter would be used to update the mixing code every time
the output frequency of a sound channel changed.

[TUHS] Harvard and Von Neumann Architectures and Unix

[Steve Simon]

> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.

It is a typical of designs by Rob Pike, a thing of great elegance.
See here: https://9p.io/cm/cs/doc/87/archtr.ps.gz

-Steve

[TUHS] Harvard and Von Neumann Architectures and Unix

[Bakul Shah]

> On Nov 25, 2017, at 6:24 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Doug McIlroy
> 
>> Optimal code for bitblt (raster block transfers) in the Blit
> 
> Interesting case. I'm not familiar with BitBLT codes, do they actually modify
> the existing program, or rather do they build small custom ones? Only the
> former is what I was thinking of.

This was the only way we could handle four 9600 baud serial connections
on a 5.5Mhz 68000 processor. Back then the UART we used only buffered
one character (also the case with the old 16450) - so one interrupt per char.
And we "discovered" devices at runtime. So Yost wrote some code to hook
up customized interrupt handlers that stuffed a larger char buffer specific
to each UART. Essentially "partially evaluated" interrupt handler code to
minimize memory accesses. A separate s/w interrupt was used to service
the larger buffers.

This was done at boot time but another instance of self-modifying code
(that is not a virus) at runtime was by the old gcc compiler - don't know
what it does now - but pointer to a GNU C's lexically nested function was
actually a piece of code that was constructed at runtime with hardwired
static link in it (recall that a nested function can reference variables from
its lexical environment but normal C function pointers are represented as
a single pointer).

[TUHS] Harvard and Von Neumann Architectures and Unix

[Doug McIlroy]

> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, [...]
>
> It's just a Bad Idea.

Surely JIT compiling must count as self-modifying code.

Optimal code for bitblt (raster block transfers) in the Blit

[TUHS] Harvard and Von Neumann Architectures and Unix

[Jon Steinhart]

Doug McIlroy writes:
> Optimal code for bitblt (raster block transfers) in the Blit

Oh yeah, forgot about this one.  I did a version of this for
the 68020 which was blazingly fast when the generated code
fit into the instruction cache.

Jon

[TUHS] Harvard and Von Neumann Architectures and Unix

[ron minnich]

Self modifying code is in your life every day, if you use Linux. There was
a pretty nice talk on it a few years back at ELC.

On Fri, Nov 24, 2017 at 8:17 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Doug McIlroy writes:
> > Optimal code for bitblt (raster block transfers) in the Blit
>
> Oh yeah, forgot about this one.  I did a version of this for
> the 68020 which was blazingly fast when the generated code
> fit into the instruction cache.
>
> Jon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171125/8ceae33a/attachment.html>

[TUHS] Harvard and Von Neumann Architectures and Unix

[Ralph Corderoy]

Hi Doug,

> Surely JIT compiling must count as self-modifying code.

If it does, then my computer just runs one program from when I turn it
on.  It switches memory formats and then is forever extending itself and
throwing chunks away.

_The Story of Mel_ about self-modifying code is well known.  What some
that read it a long time ago might not know...  Mel has been identified.
http://www.catb.org/jargon/html/story-of-mel.html

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] Harvard and Von Neumann Architectures and Unix

[Noel Chiappa]

    > From: Will Senn <will.senn at gmail.com>

    > I am curious about how the Harvard Architecture relates to Unix,
    > historically. If the Harvard Architecture is predicated on the
    > separation of code from data in order to prevent self-modifying code (my
    > interpretation)

That's not the 'dictionary' definition, which is 'separate paths for
instructions and data'. But let's go with the 'no self-modifying code' one for
the moment.

The thing is that self-modifying code is pretty much an artifact of the dawn
of computers, before the economics of gates moved from that of tubes, to
transistors, and also before people understood how important good support for
subroutines was. (This latter is a reference to how Whirlwind did subroutines,
with self-modifying code.) Once people had index registers, and lots of
registers in general, self-modifying code (except for a few small, special
hacks like bootstraps which had to fit in tiny spaces) became as dead as the
dodo.

It's just a Bad Idea.

    > then it would seem to me to be somewhat at odds with a Unix philosophy
    > of extreme abstraction (code, data, it's all 0's and 1's, after all).

The people who built Unix were fundamentally very practical. Self-modifing
code is not 'practical'. (And note that Unix from V4:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/text.c

onward has support for pure text - for practical reasons).

    > the PDP-11 itself, with the Unibus and apparently agnostic ISA seem to
    > summarily reject the Harvard Architecure...

You could say that of a zillion computers. The only recent computer I can
think of offhand with separate instruction and data paths was the AMD 42K
(nice chip, I used it in a product we built at Proteon). They had separate
ports for instructions and data purely for performance reasons. (Our card had
a pathway which allowed the CPU to write the instruction memory, needed during
booting, obviously; the details as to how we did it escape me now.)


    > From: Jon Steinhart

    > For all intents and purposes instructions were separate from data from
    > the PDP 11/70 on.

s/70/45/.

And the other -11 memory management (as on the /40, /23, etc) does allow for
execute-only 'segments' (they call them 'pages' in the later versions of the
manual, but they're not) - again, separating code from data. Unix used this
for shared pure texts.

And note that those machines with separate I+D space don't meet the dictionary
definition either, because they only have one bus from the CPU to memory,
shared between data and instruction fetches.

       Noel

[TUHS] Harvard and Von Neumann Architectures and Unix

[Jon Steinhart]

Noel Chiappa writes:
> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, before the economics of gates moved from that of tubes, to
> transistors, and also before people understood how important good support for
> subroutines was. (This latter is a reference to how Whirlwind did subroutines,
> with self-modifying code.) Once people had index registers, and lots of
> registers in general, self-modifying code (except for a few small, special
> hacks like bootstraps which had to fit in tiny spaces) became as dead as the
> dodo.
> 
> It's just a Bad Idea.

The one practical and Good Idea place for self-modifying code that I
encountered was the software implementation of floating-point for
516-TSS runnning on the Honeywell 516.  Our code modified the count
in the shift instructions for normalization.  Any other approach would
have involved looping.  Granted, an instruction set that took the
shift count from a separate register would have made this unnecessary
but that's not what the 516 had.

Jon

[TUHS] Harvard and Von Neumann Architectures and Unix

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On CDC machines, the return jump (RJ) instruction generally used to call subroutines deposited a jump instruction (EQ B0,B0,caller+1) in the called routine and jumped to the word after it.  Clearly, languages like Pascal didn’t use that.

I seem to recall that the CDC SORT routine built and executed sort computations in memory, a la bitblt, which came a few years later. Of course, CDC had no concept of I and D space.  We aren’t talkin’ Burroughs here….

ches

[TUHS] Harvard and Von Neumann Architectures and Unix

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

On Sat, 25 Nov 2017, William Cheswick wrote:

> On CDC machines, the return jump (RJ) instruction generally used to call 
> subroutines deposited a jump instruction (EQ B0,B0,caller+1) in the 
> called routine and jumped to the word after it.  Clearly, languages like 
> Pascal didn’t use that.

Ahhh; that brings back fond memories of my Cyber-72 days, and how easily 
we CompSci kiddies broke into KRONOS...[*]

One of my favourite machines was the PDP-8; the JSR instruction planted 
the return address in the first word and jumped to the second word, with a 
return being done (IIRC) by an indirect jump to the first word. 
Recursion?  What's that?

[*]
Can't remember it now, but (on an LA-36 Duckwriter) it was something like:

     COMMON POOL
     RELEASE POOL
     (intr)

     (Could be abbreviated to "COMMO POO" and "REL POO" for those with a
     sick sense of humour, which was most of us.)

and you got system privileges...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Harvard and Von Neumann Architectures and Unix

[Mike Markowski]

On 11/24/2017 04:43 PM, Noel Chiappa wrote:
> The thing is that self-modifying code is pretty much an artifact of the dawn
> of computers, [...]
> 
> It's just a Bad Idea.

But what devious exam questions come from it!  :-)

Mike Markowski

[TUHS] Harvard and Von Neumann Architectures and Unix

[Dave Horsfall]

On Fri, 24 Nov 2017, Mike Markowski wrote:

>> The thing is that self-modifying code is pretty much an artifact of the 
>> dawn of computers, [...]
>> 
>> It's just a Bad Idea.
>
> But what devious exam questions come from it!  :-)

You too, huh?  :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Harvard and Von Neumann Architectures and Unix

[Will Senn]

I am curious about how the Harvard Architecture relates to Unix, 
historically. If the Harvard Architecture is predicated on the 
separation of code from data in order to prevent self-modifying code (my 
interpretation), then it would seem to me to be somewhat at odds with a 
Unix philosophy of extreme abstraction (code, data, it's all 0's and 
1's, after all). In my naive understanding, the PDP-11 itself, with the 
Unibus and apparently agnostic ISA seem to summarily reject the Harvard 
Architecure...

My question is - was there tension around Harvard and Von Neumann 
architectures in Unix circles and if so, how was it resolved?

Thanks,

Will

-- 
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

[TUHS] Harvard and Von Neumann Architectures and Unix

[Jon Steinhart]

Will Senn writes:
> I am curious about how the Harvard Architecture relates to Unix, 
> historically. If the Harvard Architecture is predicated on the 
> separation of code from data in order to prevent self-modifying code (my 
> interpretation), then it would seem to me to be somewhat at odds with a 
> Unix philosophy of extreme abstraction (code, data, it's all 0's and 
> 1's, after all). In my naive understanding, the PDP-11 itself, with the 
> Unibus and apparently agnostic ISA seem to summarily reject the Harvard 
> Architecure...
> 
> My question is - was there tension around Harvard and Von Neumann 
> architectures in Unix circles and if so, how was it resolved?
> 
> Thanks,
> 
> Will

I don't know how to answer this question directly but in my opinion the
distinction between von Neumann and Harvard architecture machines became
moot with the introduction of memory management units.  For all intents
and purposes instructions were separate from data from the PDP 11/70 on.

Jon

[TUHS] Harvard and Von Neumann Architectures and Unix

[Tony Finch]

Will Senn <will.senn at gmail.com> wrote:

> In my naive understanding, the PDP-11 itself, with the Unibus and
> apparently agnostic ISA seem to summarily reject the Harvard
> Architecure...
>
> My question is - was there tension around Harvard and Von Neumann
> architectures in Unix circles and if so, how was it resolved?

Well, there were PDP-11 models with split instruction and data address
spaces, so you could address 64K of code and 64K of data without overlays.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7,
occasionally gale 8 except in Shannon. Rough or very rough, occasionally
moderate. Squally showers. Good.