Segmentation violation

[Fairlight]

When asked his whereabouts on Thu, Dec 06, 2007 at 12:16:00PM -0500,
Kenneth Brody took the fifth, drank it, and then slurred:
> The filePro virtual machine (to use today's buzzwords) uses 16-bit
> addressing, and the original 64K code limit was plenty at that time.
> Back in 3.0 or 4.0 (I forget which), the engine was retrofitted to
> allow two 64K code segments, without breaking the existing code base.

That sounds suspiciously like a 6502 (specifically in the Apple 2 series
computers), in that it could only address 64K at a time.  The Apple
expansion memory that added a second 64K was almost useless, however, as
the chip could only address one 64K memory segment at a time and had to
page between the two segments.  I can think of only about three programs
that ever used the extra RAM.

Which sounds suspiciously like the x86 "extended memory" screwup that Bill
Gates started with, "Nobody will ever need more than 'x' RAM!"  You'll note
that finally went away about 1995.

Which sounds suspiciously like being able to only access about 137GB of a
HD.  The need for arcane workarounds has all but vanished there as well.

> (Does "the engine uses X-bit addressing" fall under your definition
> of "artificial limits"?  Does one need to use infinite-bit addressing
> to eliminate "artificial limits"?)

How long do you think C would have lasted as a useful language if programs
were limited to a certain length or completed binary size?  Nevermind
anything newer built on top of C as a 4GL...  "Oh, sorry, X11 compiled too
large.  It won't work."  "You can't program a perl script longer than 'x'
lines because the resultant precompiled code is too large, sorry.  Find a
shorter way to do your (unshrinkable) task."  That just doesn't fly.

If it constrains the programmer without need, yes, I feel it's less than
desirable.

In a case where people had < 9999 lines of code and still hit this
boundary, I think that falls under "misleading published performance
characteristics".  The specs only cite lines of code possible per table,
not some arcane limitation based on the end result size for the VM.  The
short version is that nobody cares about the internals.  They were promised
it could do up to 9999 lines of code, and ";" was a valid operand
separator--they should have been able to pack as much code into 9999 lines
as physically possible because the published product specs say so in an
unqualified fashion, TTBOMK.

mark->