Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: MEMF_PHYSICAL?
Message-ID: <7138@cbmvax.UUCP>
Date: 27 Jun 89 02:30:26 GMT
References: <8906030123.AA14671@jade.berkeley.edu> <7060@cbmvax.UUCP> <96@estinc.UUCP>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 30

In article <96@estinc.UUCP> fnf@estinc.UUCP (Fred Fish) writes:
>Anyone who has ever
>ported Unix to a new hardware configuration is familiar with the problem of
>programs that break when you run them on your new wizzbang hardware that
>maps text at 0x100000, rather than 0x1000 (or worse, 0x0) where it was on
>your last machine.

	Well, maybe, but usually that's the result of a lurking bug that was
there all along.  The most famous of these is the infamous "null pointer
dereference" common among programmers used to working on BSD Vaxen.

	We're working on improving your ability to make programs crash for
these reasons, via a suite of stuff that can make the system VERY unforgiving.
Sort of like a super-memmung - stuffs freed memory with garbage odd values,
corrupts location 0, moves stuff around, checks for low-memory trashing,
has some double-checks (like the Bryce's new io_torture) on system calls to
catch common mistakes, like reusing an in-use message, etc.  Not perfect at
catching them, and definitely slows down the system, but good for developers
doing testing.  We may also use the MMU to catch other mistakes, like
accessing non-existant (or maybe even free) ram (ala setcpu TRAP).

	Phew, only 270 more messages to read in .tech!  :-(  That's what I get
for going to devcon, then being afraid to even look at news for a week after-
wards!

	Thanks to all who voted for me in Marco's survey/whatever, it's nice
to know your help is appreciated.

-- 
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup