From: gryphon@crchh424.BNR.CA (Joe Widows)
Newsgroups: comp.os.minix
Subject: A small appology and some context questions
Keywords: ATARI,ST,MINIX
Date: 13 Apr 92 06:02:17 GMT
Reply-To: gryphon@bnrrch43.bnr.rich
Organization: BNR


 1. Sorry, if it takes so long to reply to a post. I have a 10 day delay.
 2. Sorry, if I was terribly irritable about the code. I knew I had the sources
    and I was cranky because I could not find them.  MEA CULPA.
 
  Let me start out by saying that I have not looked at much of the code because
  there does not seem to be any syntax faults in it.  All I am doing is 
  compiling, and building code maps.
    
  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.  
     
  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.
         
     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.
         
    These things are being generated by a UNIX compatible compiler and K&R
    compliant. Lattice and Laser dislike the code entirely.
    
    
    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
    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
    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
    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
    it 68K specific, then the locking should be 68k stuff not IBM stuff.
    Do we have any sources common to IBM?
    
    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
    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. 
    
    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.
    
    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
    me would be appreciated.  I took up MINIX to learn C ( my 10th or 11th
    programing language) I do not consider myself expert in C at all, but I
    do understand what is happening.
    
    I am upgrading my machines. ( tried to upgrade a 520 to 4 megs and ended up
    with a MEGA2 upgraded to 4 megs.)  later this year I will get the
68030 from
    ICD and the virtual memory.  I do not have a TT because they have only
    just last month become available in the USA.  Here in Dallas, no-one really
    knows what an ATARI can do.  I have a dealer, which is better than most.
    
    As soon as I can get an ID on the GATEWAY, We could exchange email. I think
    you can email me at GRYPHON@CRCHH424.BNR.CA.  I'm not sure.  maybe the
    reply in the header will work or some combination.  I would have emailed
    you but I can't, yet. If you succeed, I will get the message via 370 and
    corporate mail (cocos), Please don't send me any binary. and there is a
    limit of 4k on mail. Sorry, I didn't make these rules.
                                       
    widows
    
    DISCLAIMER: BNR builds telephones, not opinions.
    ANTDISCLAIMER:  The wrong stuff is mine (the right stuff too).