Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!ditsydh.syd.dit.CSIRO.AU!evans
From: evans@syd.dit.CSIRO.AU (Bruce.Evans)
Newsgroups: comp.os.minix
Subject: Re: Stupid questions about Minix-386 ...
Message-ID: <1991Apr10.165105.29438@syd.dit.CSIRO.AU>
Date: 10 Apr 91 16:51:05 GMT
References: <MIKE.91Apr8172810@client25.prg.ox.ac.uk>
Distribution: comp
Organization: CSIRO Division of Info Tech, Sydney, Australia
Lines: 72

In article <MIKE.91Apr8172810@client25.prg.ox.ac.uk> mike@prg.ox.ac.uk (Mike Spivey) writes:

>1.	Bruce's C compiler fails test 9, which seems to be about the
>	interaction between longjumps and register variables.  Is this
>	normal, and should I worry about it?

It is not quite right, but it is normal for bcc, and I don't worry about it.
The longjmp library function does not restore register variables. So the
following may fail, although it may reasonably be expected to work:

	regvar = 0;
	if (setjmp(jbuf) != 0) {
		/* expect regvar == 0 here */
		...
	}
	... /* code not changing regvar */

Compare this with

	regvar = 0;
	if (setjmp(jbuf) != 0) {
		/* expect regvar == 1 here */
		...
	}
	regvar = 1;
	longjmp(jbuf, 666);
	... /* code not changing regvar */

It's not clear what the value of 'regvar' after the longjmp should be.
If register variables are restored, it will be 0 unless the restore is
very clever. If the 'register' keyword is ignored, the value will be 1.

It seems that there is very little code depending on the behaviour in
the first example, perhaps because the difference between the two
examples is subtle so it's simplest to avoid any assumptions about the
behaviour of register variables after longjmp.

The situation becomes more interesting with an ANSI compiler. Then the
compiler is allowed to treat any local variable as 'register' unless it
is declared volatile or its address is taken. It's usually not practical
to keep volatile variables in registers because of the difficulty of
restoring them to the "current" value in the procedure being longjmp'ed
back to. So compiler implementors have to do extra work to treat setjmp
specially, an compiler users have to use volatile if they require the
behaviour in the second example for non-register local variables. ANSI
only requires the behaviour in the first example.

test9 only warns about the second example not working. For an ANSI
compiler, it shouldn't even give a warning (and most of test9.c needs
upgrading to use volatile).

bcc happens to pass most of the tests (including the one for the second
example if test9 gets that far) because it ignores 'register' except for
pointer variables. ACK compilers pass because they ignore 'register' for
all variables inside functions that call setjmp. Don't put time-consuming
things inside routines that call setjmp!

There's a trick with bcc that will allow test9 to pass, and often speeds
up other programs. Compile (entire) programs with the -C-c (caller-saves)
flag, but leave the library compiled without it.

>2.	Recompiling bcc is almost enough to allow the assembler,
>	loader and libraries to be in another place than /usr/local,
>	but the pathname /usr/local/lib is wired into ld (for which I
>	have no source).  Can I do better than patch it with de?

Oops. Mostly ld isn't run directly, but it needs the path for handling
flags like -lcurses. Patching ld with a binary editor (or elle) would
be safer. The full path string is "/usr/local/lib/", to which is appended
"i386/" or "i86/".
-- 
Bruce Evans		evans@syd.dit.csiro.au