Segmentation violation

[Kenneth Brody]

Quoting Fairlight (Thu, 6 Dec 2007 10:16:41 -0500):

> At Thu, Dec 06, 2007 at 10:04:44AM -0500 or thereabouts,
> suspect Kenneth Brody was observed uttering:
>> Prior to 5.6, there was a limit of 128K on the compiled code size.
>> Starting with 5.6, this has been increased to 2MB of compiled code.
>
> And again I wonder why there is a hard limit at all?  It had to be redone
> in the first place, and as with so many other things, instead of -removing-
> limits, they simply raise them.  So they can get to do it all over again in
> a decade or whenever.
>
> Okay...my mantra:  "NO ARTIFICIAL LIMITS."

"Backwards compatibility."

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.
For 5.6, I was able to work out a way of allowing 32 64K segments,
allowing 2MB of compiled code, without breaking the existing code
base.  Given that the only tok file that I have personally seen
which exceeds to earlier 128K limit took most of the 9,999 lines of
source code, increasing that limit 16-fold isn't going to be an
issue until we increase the line limits at some point in the future.
At that point, it may be necessary to break backwards compatibility,
and redo the filePro engine using 32-bit addressing.

(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"?)

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com