glk01126@uxa.cso.uiuc.edu (10/30/89)
Could someone out there send me the GEMQ libs for sozobon? With the startup code... (I can't get it to find int_in etc.) Thanks in advance... -Spieu!
steve@thelake.UUCP (Steve Yelvington) (10/31/89)
In article , glk01126@uxa.cso.uiuc.edu writes ... > Could someone out there send me the GEMQ libs for sozobon? > With the startup code... (I can't get it to find int_in etc.) > Thanks in advance... > -Spieu! ****Please note that int_in and intin are not the same thing.**** The startup code is the first module in the AESQ.A library archive (which I sent you the other day), entitled "header.o." It defines the following globals: _aespb 18 global external abs _vdipb 14 global external abs _control a global external abs _global 20 global external abs _int_in 22 global external abs _int_out 10 global external abs _addr_in c global external abs _addr_ou 8 global external abs _gl_apid 2 global external abs _Ix2 0 global text _appl_in 10 global text _aes 7e global text _appl_ex d0 global text (Note the leading underscore. This is conventionally used to distinguish C objects from asm objects. The underscore is automatically prepended by the Sozobon hcc code generator. In C sources, _int_in would appear as int_in.) If your GEM program calls appl_init() (which it must), this module will be linked with your program whenever you "cc -o prog.prg prog.c aesq.a". int_in[22] and its relatives are "mailboxes" used by the AES. As you see above, they are defined in the library. intin[128] and its relatives are "mailboxes" used by the VDI, which is required because the AES user-interface stuff uses VDI. For some reason, they are *not* commonly defined in libraries, even though they *always* are needed by GEM programs. Instead, the convention is to include the following declaration in one of your C source files: /* GEM-VDI arrays */ int work_in[11], work_out[57], contrl[12],intin[128],ptsin[128],intout[128],ptsout[128]; Ian Lepore's GEMFAST bindings do not use these arrays; instead, the mailboxes are created as auto variables (using stack space) on the fly. Therefore this declaration will be redundant in a program linked to GEMFAST, and often is omitted. The omission causes portability problems. If you are compiling such a program, the Sozobon linker will holler at you. If it indeed is "_int_in" and not "_intin" that the Sozobon linker is complaining about, contact me via mail (uiucuxc!pwcs!thelake!steve) and I'll try to figure out what the heck is going on. Incidentally, I exchanged mail with Ian Lepore the other day. He said GEMFAST 1.3 has been in beta test for several weeks with no bug reports, so he expects to release it Real Soon Now. Steve Yelvington, up at the lake in Minnesota ... pwcs.StPaul.GOV!stag!thelake!steve (Usenet) ... {playgrnd,moundst,class68}!thelake!steve (Citadel)