From: meulenbr@ce.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: A small appology and some context questions
Keywords: ATARI,ST,MINIX
Date: 15 Apr 92 10:02:24 GMT
Organization: Philips Consumer Electronics, Eindhoven

gryphon@crchh424.BNR.CA (Joe Widows) writes:
[...]
>  1. the dirty code:
>     I define dirty code as code that clutters up the compile with warnings.
>     There were several extra comment marks and commas.  They do not generate
>     errors, but they confound the screen so that REAL errors are often lost.
>     It is my foolish opinion perhaps that one should remove all unused vars
>     except where absolutely necessary.  These three things generated hundreds
>     of warnings. Not NICE.  

This is maybe because you do not use the standard compiler.
With the supplied compiler only a few (not dangerous) warnings occur.

As for comment in comment: perhaps this should be fixed. Maybe it
already is.

the commas problem: I don't understand what you mean with this one.
Does the compiler barf on quotes or commas in comment's? Blame your
compiler. If it is another problem, let me know (perhaps with a small
code sample)

unused variables: yes. the problem is that a lot of code is shared
between PC and 68000. A lot of unused variables are used in the other
system, surrounded with #ifdef's. Therefore either you end up with
a lot of unused variables, or you should #ifdef the declarations too.
Since ast thinks too much #ifdefs make the code unreadable he opted for
leaving in the unused variables. I follow his coding practice
ack cc does not barf on this one.
>     
>  2. BUGS.
>     1.  The structure for the ACIA is a long word.  Most compilers will try
>         to put this in a register for access.  My source incrimented the
>         pointer. (OOPS,  address error).  I also got context warnings from
>         MWC about the code.  I recoded this and introduced my own foible,
>         which I have been too lazy to fix, however, it compiles.
I don't think that is really the problem. The struct is defined as:
struct acia {
	_VOLATILE unsigned char acb[4];         /* use only the even bytes */
};

Incrementing the pointer which points to the acia struct should not be
a problem as long as you do not dereference that pointer.

>         
>     2.  GETARGS definition would cast a type onto a VOID *.  Since this is
>         a macro after all, why not cast the whole reference and replace
>void.  
>         I did this,  and the syntax fault went away.
Can you be a little more specific where this occurs and how you fixed it.
>         
>    These things are being generated by a UNIX compatible compiler and K&R
>    compliant. Lattice and Laser dislike the code entirely.

My current version (still in the works) compiles fine with the ansi ack
compiler. 1.5 is known to compile with gcc with minor tweaking of the
sources.
>    
>    In general, I would like to say that there is very little justification for
>    clever coding.  Concise and efficient, yes; but remember KISS ( KEEP IT
Which parts do you consider "clever coding" ?
>    SIMPLE STUPID )  The other thing I dislike is the common names.  files in
>    a system should always have distinct names and there should never be any
>    question about which CONST, TABLE, TYPE or any other source.  I work in a
>    GIANT os environment where we have Millions (10^6) of lines of code and 
>    hundreds of thousands of code peices.  From this point of view the 'trick'
>    of distinguising names via path is just that, a trick.  It is in the long
>    term interest of MINIX to be coherently sane and confusion be kept to a 
>    minimum.
>    
>    The #IFDEFs don't make sense.  There is IBM specific stuff locked with
>    M68000.  In the interest of economy I removed the M68000.  I did not like
That should not occur. Please point me to the places where this occurs.
>    the six or seven '-D' entries to configure my load.  It is not as if this
>    were conditional code.  It is not. It is absolute essential system code for
>    ATARI ST.  Clean this up please.  Lock the compile only if necessary.  And
What do you mean with "lock the compile" ??
>    forget about 'compatiblity' at this level.  We are too close to the machine
>    and our resources are too limited timewise  I assume that M68000 means 
>    compatiblity with AMIGA and MAC.  Or does it?  Cleanup the code and make
Yes, the M68000 code is common for ST, MAC, AMIGA
>    it 68K specific, then the locking should be 68k stuff not IBM stuff.
>    Do we have any sources common to IBM?
Yes. In principle all sources whose name does not start with st
there are a few exceptions to this rule though.
files like system.c proc.c memory.c clock.c and tty.c are common between
all minixes
>    
>    I moved the sources out of MINIX because I just do not want to nurse maid
>    the make process.  It required me to swap disks at every pass.  Sorry, I
>    have a large 1040 with compiling tools.  I can now 'MAKE' and come back
>    when it is done. Is this not easier?  Currently I have converted every
Sorry, I do not understand what you mean. What do you mean with 
"I moved the sources out of MINIX"
>    thing to Mark Williams Compiler  and the assembly also.  I have been
>    linking the kernel.  A question:  is the table in STMPX the 68000
>    vector table that goes at $400?  If so then I must relocate this table
>    myself.  MWC makes provision for this,  I just need to figueout how. 
No. The vector table goes at address $0. The space between $400 and $600
is preserved by minix. This space contains some TOS variables which are
used by minix.
>    
>    I have determined that head.s and stmpx.s form the first block of program
>    store such that the marker in head.s is the first sector of the program.
>    a loader would copy this verbatim into memory.  There after, there does
>    not seem to be any dependency requirements, unless you can suggest some.
The linker will resolve everything so order is not important.
The first block of your minix.img should be the boot block from tools
The first block of the kernel should be stmpx.o. I think it is block
2 of your boot image.
>    
>    I am trying to get NET access so that I can retrieve GCC and tools.  In the
>    mean time MARK WILLIAMS is the best I can do.  I have the tools packaged 
>    with MINIX; but I do not need the 'FAKEUNIX.C'.  I do not have either GULAM
>    nor do I have ALYSON C.  My intention at this point is to configure the 
>    kernel so that I can double-click and GO MINIX.  It may require me to 
>    concatenate the loader onto the kernel. Is this so?  Any help you can give
The loader is in boot.s This is the head of the program.
There is a program in the tos dir called minix.prg (with sources) which
can be used to launch minix from tos. Note that there is no way to get
back without rebooting. minix takes over your whole machine

Good luck,

--
Frans Meulenbroeks		 Philips Research Laboratories
Replies please to meulenbr@prl.philips.nl, and not to the From: address