Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!fernwood!franz!jkf From: jkf@Franz.COM (Sean Foderaro) Newsgroups: comp.sys.m88k Subject: proposed change to memctl() Message-ID: Date: 14 Dec 90 17:11:27 GMT Sender: news@Franz.COM Organization: Franz Inc., Berkeley, CA Lines: 121 Hello, I work at Franz Inc. porting Allegro Common Lisp to various architectures. I've run into a problem making our 88k version of Lisp compliant with the 88open standard. I believe that the problem lies in the 88open standard and I'd like to see that standard changed. While in theory a single person with a reasonable argument should be able to effect a change, in practice I suspect that it will actually need a large group of people in favor of the change for the 88open consortium to take notice. Thus I'm soliciting people to join with me to change the standard. This is the problem: a memory page can only be in one of three states: (1) read-execute, (2) read-write, (3) read Note that read-write-execute is not an option, and for Lisp we need read-write-execute (at least in a limited form) for many of our data pages. Let's examine current practice among computer architectures (for it was current practice that let us to design a memory allocation scheme that turned out to be incompatible with the 88open spec). Based on our current Lisp ports: Systems that permit read-write-execute: 68010, 68020, 68030 vax 386 370 cray cray 2 sparc Aviion (88k) [In our experience we don't need to cache flush on this machine, others may have different experiences] Systems that permit read-write-execute but require the user to explicitly cache flush: mips rs/6000 motorola 188 board (88k) Systems that don't permit read-write-execute at all: motorola 181 board (88k) [follows official 88open spec] The 88open consortium has taken a bold stand by refusing to support a mode of operation that its competitors support (and in fact that nearly every machine before it has supported.) Note that some 88k systems support read-write-execute but because this isn't a specified 88open extension no program that depends on that extension be certified by the 88open process. You might ask why we don't just change our Lisp to obey the 88open spec. Part of the reason is that it would be a lot of work. We have a very complex storage management/garbage collection scheme that has taken many man-years to write. It treats executable code like any other data objects and it garbage collects code that will never be referenced again. Changing this collector so that it segregates code vectors from other data objects would add another layer of complexity around what is already a very complex piece of code. Such added complexity would just make things worse on our other ports. And furthermore we don't see a huge number of 88k machines that require this change (in fact we've only come across one old-style Motorola development board that requires compliance with this part of the 88open spec). A second reason we don't like this part of the spec is that 88open is setting a dangerous precedent (new computers are supposed to increase functionality not reduce it!). We don't want the functionality of future system compromised by restrictions like this one as it will inhibit what software can be designed. What we propose: We don't need fine-grain read-write-execute where you write a word in memory and then jump to it and execute it. We propose a very coarse-grain read-write-execute that just forces the instruction and data caches to synchronize when this action is explicitly requested by the program. For those with access to the memctl() manual page the change is exactly this: To the table of states, add a new state, state 4, which is readable, writeable and executable. To the text description add: After memctl() is called with a state argument of 4, the region is readable, writeable and executable. However if any byte within a (4 byte) word in this region is written, then the subsequent execution of that word is undefined. The change implies that in order to write code into memory and then execute it, you must call memctl with a state of 4 between the time the code is written to memory and the time it is executed. Thus we don't need the instruction cache snooping the data cache. All we need is for the operating system to be able to flush a region of the data cache to memory and to be able to clear a region of the instruction cache. I think that every version of Unix that does paging will already have this capability. I'd like those who support this change to contact me (via email, phone, or comp.sys.m88k). Please mention why you want it (e.g. you have an application that requires it or you simply believe that it is correct). I'd also like to hear from hardware and operating system people who believe that implementing this would greatly slow down or otherwise hamper programs running on the 88k, even if they didn't use read-write-execute pages. - John Foderaro voice: 415 548 3600 Franz Inc fax: 415 548 8253 email: jkf@franz.com -or- uunet!franz!jkf