[LMH]Exploiter progress

[Nyef]

On Fri, 23 Aug 2002, Paul Fuqua wrote:

>     Date: Thu, 22 Aug 2002 22:36:29 -0400 (EDT)
>     From: Nyef <nyef@softhome.net>
>
>     I've just pushed a new tarball to:
>     http://www.dridus.com/~nyef/lispm/exploiter/exploiter-9c0822.tgz
>
> I finally tried it;  it compiles and runs without trouble on FreeBSD
> 4.5.

This is good to hear.

>       The only problem I had was that my load-band file was read-only,
> and your program wants to mmap() it read/write;  until you get to the
> point of saving a band, I don't think you'll need to write to one.

It's mapped read/write and private. That is, the program can modify it,
but shouldn't be saving the changes back to the disk.

It's mapped read/write because if it were mapped read-only I'd have to
simulate the copy-on-write behavior of the VM, which would mean simulating
a lot more of the VM than I do currently (although this would mean that
I'd have the PHT done, and obviate having to fake up %PAGE-STATUS).

Both the Stevens book (Advanced Programming in the UNIX(R) Environment)
and the man page for mmap(2) say that you cannot use PROT_WRITE with a
read-only file, even if you use MAP_PRIVATE. No mention is made in either
location of possible interactions with mprotect(2).

>     This release contains a couple new miscop handlers, and gets to the first
>     invocation of %PAGE-STATUS (from deq-element in micronet/queue.lisp),
>
> I used a different band, which stopped in TRUNCATE-1 (undefined miscop)
> in SYS:%INITIALIZE-TV-SCREEN-MEMORY.  It'll probably fetch up against
> %PAGE-STATUS itself once it gets past this one.

I have another band image which stops somewhere else, but I figured I'd
stick with the N928.LOAD that is supposedly the current E3 test candidate.

>                               pf

Thank you for your feedback. (sounds so trite and formulaic, doesn't it?)

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net