Fergus Henderson wrote:
>
> On 10-May-2000, Sverker Nilsson <[EMAIL PROTECTED]> wrote:
> >
> > Relevance for Haskell would be that you wouldnt be able to fork a
> > program written in C into a protected environment (functional
> > sandbox?) and know that its result would depend only on its input
> > arguments. So you couldnt safely do this thru an ordinary Haskell
> > function call that could be cached for example.
>
> Well, you don't have that guarantee anyway.
> C has many areas of undefined and/or unspecified behaviour.
I know, but I don't see how that makes the execution of the machine
code undeterministic.
To make the C source-code program itself deterministic (as well as the
object code), you might want to run the compiler as well in a
'functional sandbox'. Then I think it should be possible to have the
compiler/C program combo behave completely deterministic. If the
hardware architecture doesn't bite you though...
> There is no guarantee that C code will be deterministic.
> So do operating system ABIs. Even hardware architectures often have
> areas of undefined and/or unspecified behaviour.
Yes, but nondeterministic? You have an example below but I am
not sure if this is intrinsic to the hardware or rather describes
how a particular OS handles context switches.
>
> To give you a practical example: on SPARCs, the contents of
> uninitialized stack slots are unspecified, and in practice they are
If it's unspecified in the hardware spec, well, then it seems the OS
would have to initialize it before it starts a process. An OS should
make sure, at the minimum imo, that no information can leek between
processes (via context switches or otherwise) that could be used for
security breaches. That's a reason memory and stack space is normally
initialized (to zero).
> nondeterministic. This happens because the SPARC's register windows
> get flushed to the stack when a context switch occurs, and the timing
> of context switches is in general nondeterministic. If you write a C
Which OS on the Sparc are you referring to?
Seems to me that this OS doesn't support transparent context
switches. Well, to create totally deterministic machine-code execution
environments, it seems clear to me that one would in general have to
make modififications to the OS and/or hook into it.
This stack problem seems to require some modification to the
scheduler. I dont know about the SPARC architecture, but in this case
I would think the scheduler should have to restore the stack contents
to what it was before the context switch, writing it back to the
registers. Might be slower than the presumably optimized way it is
done right now, but that could be a price worth paying. Hopefully the
hardware architecture doesn't make it completely impossible though...
or would you say it does?
> program that examines uninitialized stack slots -- for example one
> using a conservative garbage collector -- then the program's exact
> behaviour can be nondeterministic. (This has bitten me in the past.)
I was surprised to hear about that (too).
Thanks for the information!
Sverker
>
> --
> Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
> PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
