Newsgroups: comp.os.minix
Subject: Re: Problems changing click size
References: <HrvQ2.20551$cq3.692908@news.uswest.net> <37129037.0@isc-newsserver.isc.rit.edu> <2_dR2.21774$cq3.892276@news.uswest.net>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <37160c2e.0@isc-newsserver.isc.rit.edu>
Date: 15 Apr 1999 11:56:30 -0500
X-Trace: 15 Apr 1999 11:56:30 -0500, grace.isc.rit.edu
Lines: 73
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.3.100
XPident: Unknown
Path: star.cs.vu.nl!newsfeed.amsterdam.nl.net!sun4nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-peer1.sprintlink.net!news-in-west1.sprintlink.net!news.sprintlink.net!isc-newsserver.isc.rit.edu!aje9383
Xref: star.cs.vu.nl comp.os.minix:35247

In article <2_dR2.21774$cq3.892276@news.uswest.net>,
Johnathon McAlister <maccer@uswest.net> wrote:

<Rounding clicks up/down in macboot.c--needs changing with click size>

>1) Turns out "macboot.c" doesn't include "const.h".  As a quick test, I
>hard-coded the appropriate constants into the defines for 2KB clicks (yech!)
>- will fix later if things work out...
>
>2) Hurray (kind of)!  Since it's only a partial build, it only takes 1 hour!

Oy!  On a true-platinum SE, doing something like this would take a few
minutes (with the ACK compiler--perhaps five or so).

>3) Darn!  Crashes (in both environs) after displaying the boot memory stats
>(I'd then expect to see "hd1 mounted").  This tells me we've gotten past
>"macboot" and are into the kernel, right?

Most likely--the last thing macboot does before turning over execution to
the kernel is to undisplay its loading stuff dialog box (with all the
addreses).  If anything happens after that, then the kernel was running.

>4) Took a _real_ quick peek in the kernel stuff, and guess what I found -
>more hard-coded dependencies!  "src/kernel/copy68k.s" has several places
>where a click address in a 68K register is shifted by 8 bits to create a
>physical address.  There's some worse looking stuff in there, as well
>(inline expansion of code to xfer 64 bytes is looped through 4 times = 256
>bytes).  Seems to me the easiest way to fix would be to replace "copy68k.s"
>with "copy68k.c", which would be a C version that functions like the 68K
>version (maybe a bit slower).  Being high level, it would be easier to tweak
>into using click sizes other than 256 bytes.
>
>My question is "what do I need to do to make the C functions look like 69K
>subroutines?"  The routines in the file are: "_flipclicks", "_zeroclicks",
>"_copyclicks", and "_phys_copy".  Are the leading underscores simply for the
>linker - the C versions would then be without them in the name?  What about
>the parameter passing conventions?

Take a peek in proto.h; the prototypes are there (albeit in the wonderful
macro-definition form to allow both K&R and ANSI c to be seen by an
appropriate compiler and neither by the programmer).

Something like:

void flipclicks( phis_clicks src, phys_clicks dst, phys_clicks count );

and so on and so forth.

The C versions will be substantially slower than the assembly ones.  I'd
suggest keeping at least phys_copy around and redefining copyclicks as a C
wrapper around it.  phys_copy does not make any assumptions about the size
of clicks or anything like that.  phys_copy is used all over the place in
the kernel, and a slower version of it would most likely be quite noticible.
Why copyclicks is not already a wrapper for phys_copy is beyond me; doing so
would not slow things down much at all and avoid some assembly foolishness.

flipclicks is only used when shadowing, so a slower C version would probably
be okay; things don't tend to stay shadowed very long, usuallly, since it's
generally slow all around.  (I think it's only used when a shadowed process
exceeds a time quantum; usually, the exec() will have happened by then.)

Zeroclicks is called when things are exec()'d, and a reasonable C version
(or a C wrapper to a more generic assembly routine) would probably work
fine.

>I assume I'd then change the make file to refer to "copy68k.c" instead of
>"copy68k.s", relying on the default rules to realize it's a C program to
>generate "copy68k.o".  Is that so?

Basically, yes; it would be a good idea to put in the dependencies, as well.

--Andrew Erickson, aje9383@grace.isc.rit.edu

