mike@prg.ox.ac.uk (Mike Spivey) (04/08/91)
... at least they're not about the demo disk! 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? 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? 3. Has anyone ported the Jove editor to Minix? If so, please mail your experiences. I seem to have it working, and will post patches if I turn out to be right. 4. Jove requires two things connected with process groups to manage interactive sub-processes: a. a setpgrp() system call with two process numbers as arguments that sets the 'process group' of the first arg to be the second arg; and b. the possibility of passing a negative number -pgrp to kill(), with the effect of killing all processes in process group pgrp. Both are easy enough to add with small changes to MM, but can anyone post me man pages for sensible implementations of these in other versions of UNIX? I'm particularly interested in the proper pre-condition of setpgrp() -- Jove uses it only in the form setpgrp(pid, pid) where pid is the calling process. Maybe they are in POSIX (in which case I apologize for not having been able to look), and maybe they are not in POSIX (in which case I apologize for mentioning them). -- Mike Spivey
agm@daphne.stl.stc.co.uk (Andrew G. Minter) (04/09/91)
In article <MIKE.91Apr8172810@client25.prg.ox.ac.uk>, mike@prg.ox.ac.uk (Mike Spivey) writes: |> 2. Recompiling bcc is... You mean you have the source for BCC? I'm using GCC at the moment and it's great, but it's also huge and slow. BCC is very nearly all I need, but not quite. Given the sources I'd like to work on it a bit! Is there any way I can obtain a copy? Bruce? Thanks in advance, Andrew
nall@cs.utk.edu (John Nall) (04/09/91)
In article <4192@stl.stc.co.uk> agm@daphne.stl.stc.co.uk (Andrew G. Minter) writes: >In article <MIKE.91Apr8172810@client25.prg.ox.ac.uk>, mike@prg.ox.ac.uk >(Mike Spivey) writes: >|> 2. Recompiling bcc is... > >You mean you have the source for BCC? I'm using GCC at the moment and >it's great, but it's also huge and slow. BCC is very nearly all I need, >but not quite. Given the sources I'd like to work on it a bit! > >Is there any way I can obtain a copy? Bruce? > That did not mean what you THOUGHT it meant :-). You also have a copy of cc.c don't you? It is only a little traffic cop - not the compiler itself. And no, Bruce has not released the compiler, so far as I am aware. John Nall
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/10/91)
What about tryinc c386 if you are concerned about a compiler with source? c386 may just replace GNU C. That means your toolbox will be GNU cpp, as, ld, ar and c386. Personally, I dont work with c386, so it is necessary YOU work with it to develop it further. C.v.W.
evans@syd.dit.CSIRO.AU (Bruce.Evans) (04/10/91)
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
hp@vmars.tuwien.ac.at (Peter Holzer) (04/17/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >What about tryinc c386 if you are concerned about a compiler with source? >c386 may just replace GNU C. That means your toolbox will be >GNU cpp, as, ld, ar and c386. >Personally, I dont work with c386, so it is necessary YOU work with it >to develop it further. I can highly recommend c386. It produces much better code than bcc and it implements a larger subset of C.I wrote a backend that generates code for Bruce's as instead of gas (Gas uses bitfields and cannot be compiled with bcc, and I did not try to crosscompile it on a workstation). Took me about an afternoon. I have not yet tested it properly, but I did not have any problems in the last two weeks. I will try to recompile c386 with itself, and if that works I will consider it tested and will post it if there is interest. Christoph, I had to change not only out386_gas.c but a few other files also to make it work. Do you want to have a look at it before I post the diffs? Also, compliments on your clear code. It was much easier to find out what I had to change than I had expected. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |