wright@hsi86.hsi.com (Gary Wright) (05/14/91)
I am in the process of porting ISIS 2.1 to Data General's AViiON machines. The DG/UX environment is basically System V with a version of the GNU C compiler for the 88000 chip. I have made a first pass at modifying the ISIS tasking system for this environment but I am still having trouble compiling clib to test it. The function do_bcast in cl_bcast.c seems to construct a new task and in the process duplicates the stack of the current task. The code at the very end of the function seems to make a couple of assumptions: 1) all the arguments are on the stack 2) va_list is of type (char *) Neither of these assumptions are true in this environment because GNU C passes arguments using registers and the stack. va_list is actually a structure that is manipulated by va_start and va_arg. So my question for the net is has anyone ported ISIS 2.1 to this environment or a similar environment (i.e. GNU C or register/stack passing conventions) and can they provide any tips? I'd like to avoid getting into all the gory details of varargs.h if possible. If you have ISIS 2.1 ported to a 386 version of unix (SCO Xenix/Unix) I'd also like to get in touch with you. Thanks in advance. -- Gary Wright ...!uunet!hsi!wright 3M Health Information Systems wright@hsi.com
ken@CS.Cornell.EDU (Ken Birman) (05/16/91)
In article <3606@hsi86.hsi.com> wright@hsi86.hsi.com (Gary Wright) writes: >I am in the process of porting ISIS 2.1 to Data General's >AViiON machines. The DG/UX environment is basically >System V with a version of the GNU C compiler for the >88000 chip. > >I have made a first pass at modifying the ISIS tasking system for >this environment but I am still having trouble compiling >clib to test it. The function do_bcast in cl_bcast.c seems to >construct a new task and in the process duplicates the stack >of the current task. The code at the very end of the function >seems to make a couple of assumptions: > > 1) all the arguments are on the stack > 2) va_list is of type (char *) > >Neither of these assumptions are true in this environment because >GNU C passes arguments using registers and the stack. >va_list is actually a structure that is manipulated by va_start >and va_arg.... > It may be useful to understand where this use of varargs comes from. Basically, ISIS has three "problems" involving varargs. 1) ISIS assumes that the version of varargs.h that it pulls in from the include area will work from all callers. This is mostly an issue when you mix languages, i.e. use a version of gcc that passes arguments in registers but call code compiled with cc. Normally, things work correctly because the compiler is supposed to support taking the address of an argument and if it can't analyze the target procedure it has to assume the worst. 2) When you use bcast_l("f"....) we need to fork of a task that can see the variable arguments to the caller task. We do this by copying the stack frame and then relocating the va_list to point into the new frame. This is done by adding the offset between the old frame and the new to the pointer, which is indeed assumed to be a pointer. One can probably fix this with a little knowledge of how the GCC varargs.h works. Registers will be inherited by the new thread in this case, if that might be an issue. 3) When you use bcast(....., nwanted!=0, "replyfmt", args) msg_fmt.c must rescan the section of the argument list several times, from the format on down (once per reply message, basically). We probably should use a macro for this -- a sort of va_checkpoint(ap, &save)... va_reset(ap, &save) Currently, we just do "save = *ap .... *ap = save" for this purpose. A similar scheme is used when scanning the format notation {...}[], but since this is a very obscure ISIS feature, one could just as easily disallow that feature if it poses a problem. -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428