Re: Compilation of Minix kernel and clock & system tasks on Linux done!


Nice effort.
Thanks Antoine.


However, I see a couple of problems at first sight:

* The code in multiboot.h and boot.S is inappropriate for licensing reasons:
either you make your whole project GPL (but please make it clear); or you've
to restrict yourself to not include any GPL'ed code; I believe you should
also include the src/LICENSE from the original distribution.

I am not so familiar with license related nuances.
I was going to use a nasm file instead and drop both the files
shortly.


* I do not understand clearly why you are using nasm instead of GNU
assembler (using asmconv); anyway, the code in several .nasm files like
lib/i386/misc/io*.nasm seems to be using 16-bit mnemonics and conventions,
but producing the codebytes adequate for 32-bit mode (obtained with ndisasm
but you didn't pass the -b32 option?): the assembled result will be wrong
when passed to nasm -f elf (which expects normal 32-bit code.) Other .nasm
files in the distribution seem to not be translated at all from the original
Xenix/ACK dialect.
Well ... I just am much more familiar with the Intel syntax and
besides, I remember reading
somewhere that GNU's assembler was intended from assembling assembly
emitted by the
compiler so its not so programmer friendly. But its really the
familiarity with the intel syntax :)


* Do pass the -ffreestanding flag to GCC when compiling the kernel, else GCC
may intend some nasty optimisations which are usually OK for hosted code
(i.e. code linked with a standard libc.a library), but could prove wrong for
a kernel; check the relevanthttp://gcc.gnu.org/onlinedocs/gcc-V.V/gcc/C-Dialect-Options.html(replace
V.V with the appropriate value) page for the gory details; this may have the
effect to request the link-in of several more str* or mem* functions, which
GCC will _not_ substitute automatically like it does in -fhosted mode: then
use the appropriate #define mem... __builtin_mem... if needed.
Thanks - I will look into the details



* You forgot to pass -D_EM_WSIZE=4 -D_EM_PSIZE=4 (or perhaps =__WORDSIZE
instead of hardcoded 4), which are predefined by ACK compiler and assumed by
several source files, but unknown to vanilla GCC. ACK used to predefine
also -D_EM_SSIZE=2 -D_EM_LSIZE=4 -D_EM_FSIZE=4 -D_EM_DSIZE=8, but I doubt
they are actually used in the code. Of course the right fix here is to
recode all this stuff to avoid such explicit dependance, but it could prove
quite a bit trickier. The nastier use I saw was in
include/minix/sys_config.h (which is included almost everywhere :-( ):
    /* Word size in bytes (a constant equal to sizeof(int)). */
    #if __ACK__ || __GNUC__
    #define _WORD_SIZE _EM_WSIZE
    #define _PTR_SIZE _EM_WSIZE
    #endif
Yes - looks like I over looked the implication of not defining it.

Since that code is clearly a derivative of 2.0.4 (only difference is the
addition of ||__GNUC__) and not related at all with Minix-VMD, my guess is
that this is a quick fix/hack (actually r765 in SVN tree,https://gforge.cs.vu.nl/plugins/scmsvn/viewcvs.php?rev=765&root=minix...),
in phase with Minix' port of GCC, which adds this "feature" of pre-#defining
_EM_?SIZE, and fails to document it loudly :-(... See
gcc/config/i386/minix.h; in SVN it's r1765 for GCC3
(https://gforge.cs.vu.nl/plugins/scmsvn/viewcvs.php?rev=1765&root=mini...
=rev); or r2441 for GCC4
(https://gforge.cs.vu.nl/plugins/scmsvn/viewcvs.php?rev=2441&root=mini...
=rev, easier to browse.)

Hey ... Looks like I might be better off using
https://gforge.cs.vu.nl/plugins/scmsvn/viewcvs.php?rev=765&root=minix
- what's your opinion.
My intention is to be able to build a working minix kernel on Linux
(even FreeBSD for that matter). I believe this will help
in more people giving Minix a shot. I have no intention of re-doing
something that's already there.


regards,
Kashyap

.

Relevant Pages

  • Re: Updates on the X64 port
    ... I think academia will seriously benifit with the presence of an assembler in minix, ... It would probably be much easier to use GCC. ... and program code, linking programs for runtime, calling conventions, ...
    (comp.os.minix)
  • Re: FORTH levels
    ... prepared to colonize a new space would be to an '86 assembler based ... I could eliminate gas from my tools, but gcc is harder. ... this freedom of the toolchain from C means that the gforth ... model is no longer restricted to a subspace of what gcc can colonize. ...
    (comp.lang.forth)
  • Re: Auto-preservation of non-volatile registers by inline assembler
    ... GCC would produce when grepping for ebx. ... if you meant that mostly the compiler will pick ebx before any other ... to bypass the restrictions of your inline assembler. ...
    (comp.lang.asm.x86)
  • Re: Best Compiler
    ... But the GCC compiler actually itself uses the GAS assembler to do ... "GAS with a few extra complications"...GAS syntax and sent to GAS for it ...
    (alt.lang.asm)
  • Re: How do I make my own custom C compiler?
    ... to fix a bug. ... Macros everywhere hide from you what is going on. ... has been taken to ridiculous extremes (the assembler, ... For instance I am trying to understand the way gcc generates the ...
    (comp.lang.c)