newton@gumby.cs.caltech.edu (Mike Newton) (12/21/90)
Hi --
Sean Foderaro recently posted a thoughful note on the m88k open spec memctl,
including a proposal and a call for comments. I'd like to add the comments
that I sent in an e-mail message to a friend that worked (past tense) at
the 88open consortium (Michael P. Brooks). I dont know if they were
officially submitted to the ?? 88open committee (?? or whatever).
Please note that these are base on the OCS and BCS 1.0 versions, which are
out of date. I dont have newer copies. Some of these may have been fixed.
It is also possible that i misinterpreted parts, and, yes, my writing is
too informal....
Note in particular, #4, #5 and #19.
" [ .... ] " implies a deleted secion.
[Feel free to copy / distribute / ... ]
- mike
newton@gumby.cs.caltech.edu Beach Bums Anonymous, Pasadena President
Caltech 256-80 (Hilo -- it's not just another rainy day!)
Pasadena CA 91125 Life's a beach. Then you graduate.
============== sections of e-mail sent in May '90 to 88open ================
Hi,
Below are some of my comments on the OCS and BCS. Please pardon my informal
style of writing. I do not have a good idea of the audience these will be
read by, so i have tended to over-elaborate.
[ .... ]
As a brief introduction to the comments, my work/research is in compilers for
very high level languages [ .... ] addition[ly], I've written a set of
optimizers that have been used over the last seven years by various people
around the country. (Other research areas include computer applications to
biology and theorem proving.) One project from about 5 years ago was the
first Prolog compiler to acheive one million 'LIPS' (logical inferences per
second) on the full naive reverse benchmark. This was on a 3090, but due to
the number of registers on an 88k, I believe that it too could do so (modulo
the comments in the next section!). All comments are on the OCS and BCS
versions 1.0, and when line/section numbers are refered to without
stating, assume 'BCS' :
#1
The single most performance-degrading part of either the BCS or the OCS, at
least for me, is the section on memctl in the BCS. In particular, lines
1251-1252: "A conforming application shall not attempt to write to memory
that is not writeable (states 1 and 3)." This effectively destroys the
most useful aspect of the memctl() system call: the ability to do stack
overflow detection in hardware.
In languages like Lisp and Prolog, usually several different stacks are kept.
Notably, the most common methods of implementing Prolog have 4-5 seperate
'regions', and a common way of compiling lisp involves [among other things] 3
different stacks. These must be seperate from the normal ('system', or 'C')
stack. In systems without memory protection, every stack 'push' must also do
a test and branch on stack overflow. While for interpreted code this overhead
is not high, for compiled code it easily results in a 20-40% performance
penalty.
A useful technique around this performance hit is to set the stack up in
memory, such that write-protected page(s) seperate them. Then upon a
SIGBUS/SIGSEGV (the later on an 88k), stacks can be extended and/or garbage
collection can be run. (Note that it is not necessary to worry about delivery
of all possible signals dealing with the failed 'push', as these can be
easily determined by the interrupt code.)
Thus, I propose that section 9.27.2 be changed to indicate that a conforming
application can depend on a signal occuring for trying to write to a non-
writable segment. This may include a warning about imprecise interrupts etc...
#2
Partly in connection with the above, sections 7.3, 7.4 and 7.7, seem to also
have problems. First, I cannot tell from 7.3 item 1 (lines 35-37) whether
various operations will cause a hardware exception. For example, does
accessing 'write-protected' memeory (as above) cause a hardware exception?
Or, possibly, will it result in a signal generated by the kernel?
In 7.7, lines 92-94, "A conforming system shall handle exceptions caused by
the execution of a conforming application by completing the operation in a
manner transparent to the application, or by delivering a signal to the
application." By the way other sections describe operations, this sentence
seems contradictory, because a conforming application is defined as a program
that does not cause these conditions. In addition, suppose I write to
a write protected memory location. By this definition, can the system
'transparently' complete the operation?
#3
Also, the meaning of 'Exception' (implying a hardware related concept --
see lines 35-37, 41-49) seems diluted by the use in lines 116 and 117 for
what appear to be software derived signals.
#4
Neither section 5 (lines 17-19), nor 7.3, 7.4 or 7.7, nor 9.27 tell me
whether:
it is legal, in all conforming systems, to change a text page to
another type. (ie: is this something that is guaranteed to work?)
In addition:
what happens if i change the page that i am currently executing in???
#5
(related to #4 above, but more serious):
OCS, section 6.1, line 29: "All words whose address may appear as a
return address value (described below) should be in a text chunk." :
This causes problems, as "text chunk" is defined (line 16) as part of
an executable FILE. Thus it would seem impossible to ever generate
new code, load it in and memctl() it, since it is illegal to ever
have a return address in this section.
(In addition, where is 'return address value' define? Maybe a pointer
would be useful here to the right place. Line 110 has 'return address',
which i assume what was meant.)
#6
Lines 33-54 of Section 5 are very confusing.
(Maybe all the prolbems in this section are just my failure to
understand something fundamental?)
#6a Section 5, lines 38-42:
"If such extension would result in the overlap of another
segment, a SIGSEGV signal is generated."
"The stack segment may be safely extended (i.e. segment
overlap is guaranteed to generate a SIGSEGV signal) if the
stack is always extended by an amount no more
than 4 megabytes."
Either the first is true and the second should be
"... guaranteed NOT to generate ... always extended TO an amount
of no more than...."
or the second implies that asking for more than 4 megabytes might
not produce an error when it should.
#6b In addition, 'Secure stack' is used on line 49, but has never been
defined, nor is it in the index.
[ .... ]
---------------- all comments below are regarding the OCS ----------------
[ .... ]
#13
OCS 4.1.2.7 -- register 30 : "It is used when values shall be preserved for
the duration of the cuurent routine." Is rather ambiguous. At least that i
could find, none of the following sections refer to it. I know it is or was
considered a frame pointer, but this is never mentioned. The description is
identical to r14-r25, yet nothing differentiates this register
[ many more minor quibbles .... ]
#18
OCS 4.1.2.2 : When a procedure returns, must it ensure that R1 will have
the same value as when the procedure was called? (ie: can the calling
procedure rely on R1 as unmodified?
#19
Back to memctl() BCS 9.27.1 -- nothing is mentioned regarding applying
memctl() to the stack. More bluntly, nothing is mentioned that guarantees
that it will work on ANY area. If i get the proper alignment and length,
is it always legal to memctl() a data area to text? Stack?
(BCS section 5, lines 39-41 state what happens if the stack grows past the
text segment, but not what happens of memctl operates on the stack.)
[ .... ]