michaelm@bcsaic.UUCP (michael maxwell) (04/15/86)
I'm trying to bring up Ingres v7.3 from the source code supplied with BSD4.2, on a Sun II (running v2.0 of the Sun OS). Since the Ingres makefiles are written to run on a VAX or a PDP, several changes are necessary. Has anyone else tried this? The first problem is with the file "bmove.$(CPU).s" in the directory "gutil". There are two files provided, one in VAX assembler, and one in PDP assembler. Fortunately, the C equivalent is given in comments, so I created a new file "bmove.SUN.c", with the C code, and changed the Makefiles accrordingly. Hopefully this will work (albeit a bit slower than if I could code it in assembler). There's also a file "exit.PDP.s", but no corresponding VAX file; I assume this is because Ingres uses the standard C exit routines on the VAX (?). I ignored this file. The next problem is with file locv.s, another assembler file. Here I assume the PDP assembly code and the VAX code are identical, because only one file is provided. (Is that possible? I don't know either VAX or PDP assembler, nor for that matter 68K assembler.) The file is not commented sufficiently for me to figure out what it's supposed to do, although it's almost trivially short; the only comment is "C library -- long output conversion". Does anyone know what it does? There are several other error messages, but hopefully most of them will clear up when (if) I get the above problems fixed. -- Mike Maxwell Boeing Artificial Intelligence Center ...uw-beaver!uw-june!bcsaic!michaelm
anton@ucbvax.BERKELEY.EDU (Jeff Anton) (04/24/86)
Lots of little changes are required to move Ingres to the SUN. Getting it to compile and link is the easy part. (all you have to do is replace the assembly routines with existing library routines) However, the BIG problem is our old friend byte ordering. I worked with Ingres source for years before trying the SUN port. Hear are a few big and difficult to discover problems: in h/ingres.h There is a struct tup_id which looks approx. like: c_1 lineno, b0, b1, b2; which on a 68k or similar byte order machine should be: c_1 b2, b1, b0, lineno; If this is not correct creatdb will enter an infinite loop. related is iutil/utility.c struct lpage like: c_1 lpg2, lpg1, lpg0, lpgx; which on a 68k or similar byte order machine should be: c_1 lpgx, lpg0, lpg1, lpg2; If this is not correct creatdb will enter an infinite loop. I remember in dbu/modify.c there are lots of setp's of arguments that had been cast with (char *) that need to be fiddled with. In general once these problems are fixed you can do normal debugging. The mythical 4.3BSD release will contain version 8.7 Ingres which compiles and runs resonably on a SUN or similar machine. It does not pass all of our tests so it should really be looked at more. We don't have that man or machine power to track the problems down compleatly. The system might also be availble from the Sun User Group's Donated Software Distribution in the future. I can't give out diffs of what must be done because my work is based on an intermediate version. (8.5) -- C knows no bounds. Jeff Anton U.C.Berkeley Ingres Group ucbvax!anton anton@ucbvax.BERKELEY.EDU
hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (04/24/86)
I have ported 4.2 Ingres to the Pyramid 90X. This involved solving most of the portability problems, including byte order, 4 and 8 byte reals being different format, blocks of memory havinag to be on word boundaries, etc. If you want to port it to the Sun, etc., our diffs would be a good place to start. I have now prepared diffs, and would be happy to mail them to anyone who wants them. If there is enough demand, I will simply post them.