rheffel@cs2.wsu.edu (03/09/89)
Hello, I am looking for someone who already has used the TurboC compiler to compile the MINIX utilities and MINIX itself. I am wondering about the process that should be used. I am running both MINIX 1.2 and 1.3. First, I assume that all the library files (libc.a) will have to be assembled or compiled. This will form the new MINIX library under MessDos. The next step would be to compile the utility and move it from MessDos to MINIX using dos2out. Does this seem right? I want to do this because the assemble code produced by MINIX C is terrible. I also want to do it because it would be fun. Thanks in advance.
swh@hpsmtc1.HP.COM (Steve Harrold) (03/10/89)
Re: TurboC and MINIX I have begun an effort to cross-compile MINIX with Turbo C 2.0 and have progressed to the point of doing the "dos2out" step, but can get no further. dos2out ..\kernel\kernel.exe Too many relocations - stop I have had no additional time to research the problem. Any assistance from anyone?
swh@hpsmtc1.HP.COM (Steve Harrold) (03/10/89)
Re: TurboC and MINIX
Some additional info on using the TurboC compiler for producing MINIX
code.
Many (dozens) of the .ASM files are not needed for the TurboC environment
because these files are actually extensions of the "cc" command packaged
with MINIX. What this means that when the compiler wants to do something
like multiply two longs together it makes a call to one of these .ASM
routines instead of emitting the code inline. When using TurboC you
have to have a different set of such "extension" routines.
(BTW, the example of multiplying two longs may not be appropriate, but I
hope you get the idea.)
I determined by trial and error what .ASM files you actually need (i.e.
which files contain routines explicitly invoked by actual MINIX source
code):
kernel\ klib88.asm
mpx88.asm
lib\ catchsig.asm
getutil.asm
head.asm
sendrec.asm
setjmp
tools\ bootblok.asm
diskio.asm
fsck1.asm
Then, you have to build a .LIB file that contains the TurboC "extensions":
This is a section from my makefile. The names are files within the
TurboC CS.LIB file. You have to use the TLIB command to extract them
from the official file and re-package them into your own .LIB file.
This step is important because you must never LINK with the actual TurboC
libraries, otherwise you'll pick up MSDOS-specific code that is guaranteed
to fail in the MINIX runtime environment.
OBJS = ldiv.obj \
llsh.obj \
lrsh.obj \
lursh.obj \
lxmul.obj \
oldlrsh.obj \
overflow.obj \
pada.obj \
padd.obj \
pcmp.obj \
pina.obj \
psbp.obj \
scopy.obj \
spush.obj
If all this does not make sense I'm sorry, but if you're about to build
an operating system, then you had better understand a little bit
about compiler construction and a LOT about your linkers and librarians.
--
---------------------
Steve Harrold swh@hpsmtc1.hp.com
...hplabs!hpsmtc1!swh
HPG200/11
(408) 447-5580
---------------------young@cxsea.UUCP (Gary Young) (03/10/89)
In article <10426@louie.udel.EDU> rheffel@cs2.wsu.edu writes: > I am looking for someone who already has used the TurboC compiler >to compile the MINIX utilities and MINIX itself. I am wondering about >the process that should be used. I am running both MINIX 1.2 and 1.3. > First, I assume that all the library files (libc.a) will have to be >assembled or compiled. This will form the new MINIX library under >MessDos. The next step would be to compile the utility and move it >from MessDos to MINIX using dos2out. > Does this seem right? . . . You are right in principle. You have to change the 8 or 9 *.s files (use the *.asm in C86 subdirectory) and the prologue.h file so that the SEGMENT names correspond to what TurboC is doing and that they get linked in a working order. Your load modules should end up about 10% smaller (use 'ls -l' command and 'size'). If they become much larger, you probably have the wrong order and bss has been allocated in the file. You also need to take a few library routines from the cs.lib to supply functions that the compiler generates calls to. I don't remember the names here, but you can find them via tlink unreferenced errors. (They look like _LDIV _LMUL _LSHR and there are about 8 of them.) I have only played with it a small amount and on vs 1.1 for pc. Perhaps someone else will be more specific, but doing it from scratch is a valuable educational effort in itself. I recommend that you do as I did, and build the "ls" command first, dosread it, and check out your methods before committing a lot of time to something that doesn't work. Then the other commands, and finish with the boot module. Good Luck. -- Gary H. Young young@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!young +1 206 251 6098 Motorola Computer X Inc. - a Motorola New Enterprise company
mullen@sdsu.UUCP (deborah mullen) (03/11/89)
I have a TurboC environment that works great. I hacked at compress and ar so I can transfer compressed libraries to Dos via doswrite. All my minix source code has been recompiled under TurboC. The kernel is noticeably faster. The major improvement is the time to build a kernel ( for a complete recompile and link of fs, mm, kernel, and tools is about 15mins vs 2hrs under MINIX (on an XT). I modified dos2out to generate combined and separate I&D. I used TurboC setjmp.obj and setjmp.h as the MINIX one does not preserve register variables (SI and DI). If there is enough interest and I get the time, I will post a "how to" manual. It did take a lot of time to figure out all the quirks. Note: Error from dos2out "too many relocations": means you did not compile with tiny model. The small model generates far calls and returns to the TurboC compiler routines. Remember, for the dos2out (as distributed), the data segment must start on the next paragraph boundary. --Deborah Mullen
cechew@bruce.oz (Earl Chew) (03/14/89)
From article <3561@sdsu.UUCP>, by mullen@sdsu.UUCP (deborah mullen): > > Note: Error from dos2out "too many relocations": means you did not > compile with tiny model. The small model generates far calls and returns > to the TurboC compiler routines. Remember, for the dos2out (as distributed), > the data segment must start on the next paragraph boundary. > --Deborah Mullen For those of you who are interested, it is possible to compile under TC for the Small model and get the advantages of separate I&D. TC generates far calls with resultant extra relocations for the linker and .exe loader to figure out for the calls to the library support routines. These in fact can be made to be near calls. I have used two ways to do this in the past: 1. A program to scan the .exe and convert the extra far calls to near calls. The patched .exe file can then be passed to dos2out. 2. Use the Microsoft linker with /FARCALLTRANSLATION in effect. If there is interest, I can see if I can find the program mentioned in (1). Earl
Dickson@pco-multics.hbi.honeywell.com (Paul Dickson) (03/15/89)
Yes, the "Too many Relocations" does mean that some of the code you
compiled wasn't done in TINY model. Check you make file, that's were
Kevin and I had this problem.
Kevin Fleming and I are working on a port for the Slicer, but we've
first being updating our code on the PC (to get a standard 1.3 base to
work from). For the past month (read as only two sessions...) we've had
the problem that when RAM disk was being loaded the system would stop,
but TTY would continue to echo typed characters. Hitting F1 would show
us that FS was waiting for FLOPPY, while FLOPPY was IDLE. In
desparation, we pulled out our original 1.1 disks and discovered that it
did the same thing. So at 12:30 AM Sunday morning, I took the disks
into work and tried them on one of the ATs there. The 1.3 disk we were
trying to boot worked fine on the AT, but wouldn't work on our original
machine. We believe it is the floppy controller card, as that is the
only thing we can think of that has changed on the original machine
since we last booted Minix successfully (which was more than a year
ago). Has anyone else had problems with floppy controllers? I'll
followup this message when I learn the brand name of the controller.
We have put together quite a bit of tools on the DOS side for developing
Minix. We have one that changes text files for Minix by changing ^J's
to ^M^J's and another to do the reverse. We have another called
readdisk which will read the floppy disk and write it into one file on
the hard disk. Then other programs (ie. readfs?) can access the data
much faster. We another program that does the reverse (writdisk). (The
names of these programs are from memory and are usually invoke from make
files, so they may not match reality)
One of the most annoying features of DOS, is that if DOS can't read a
disk, it assumes that the disk is Single-Sided. The most reliable way
around this problem, is to format each disk before writing on it.
Other problems that I'm aware of is that some of the kernel code is
dependant on the Minix Compiler. We found a variable that was greater
than 8 characters that had different endings. The Minix compile only
looks at the first 8 characters, the Turbo linker flagged these as
undefined. They were fairly easy to find and fix.
Kevin and I a seriously thinking about writing a Minix booter for DOS,
so instead of writing a boot disk, the Minix code is loaded from the
hard disk into memory and then execution is tranfered to Minix. This
would get rid of the formatting of the floppy disk from the debug cycle.
Now that we know that our 1.3 is good, we'll update to 1.4a and attempt
to find the answer to the floppy controller problem. I'll also try to
compile a more complete list of tools that we use under DOS for Minix
development.
-Paul Dickson
ARPA: Dickson at PC-Multics.HBI.Honeywell.COMvale@caen.engin.umich.edu (marcus a vale ) (03/19/89)
For an operating systems course I took last year, we used turboc for almost all our work on modifying MINIX. The teaching assistant, who has since graduated, provided a great deal of support including ways to go from DOS to MINIX without rebooting. Because I was working on a clone which didn't have problems with the long memory check, I never used them. I always thought that he'd gleaned the procedures and ideas from this newsgroup, but they must have been his own. If anyone can get in touch with John Koepele and if he still remembers and is interested (and I can't believe his enthusiasm has waned that much) a great deal of time might be saved.