Re: "Linux ported to non MMU system"

[Johan Klockars <rand@cd.chalmers.se>]

> No, I remember that Falcon was shipped with Multitasking operating system
> with adaptive priorities scheme (well, I can't write it exactly, my RAM is

Yes, see below.

> not that good). Basically an application having keyboard I/O (or being in a
> top window?) should get higher priority (perhaps not visible in top).

In principle that's how it would be, yes.

> When I am thinking about it now - it might have been a feature of AES 4.0,
> not MiNT kernel itself...

It's the kernel (proc.c):
                /* punish the pre-empted process */
                if (curproc->curpri >= MIN_NICE)
                        curproc->curpri -= 1;

IIRC, AES 4.0 was still doing busy waiting, causing it's own priority to fall.
Wasn't this one of the things fixed in 4.1?

Something like the AES really should (IMHO) have a realtime priority, like
on the Amiga. That way it can be guaranteed to get processor time immediately
when an event, such as a button press, occurs.

> >If you raise the priority for processes that does heavy IO then gcc
> >should be on top :-)

Gcc doing heavy IO?
While I agree that loading headers and such can take a while, gcc (IME)
spends far more time on the actual compiling work, with no IO taking place.
I always run with -O2, though, and I guess things might be very different
if you don't turn on the optimizer.

> you mean disk I/O? How can you measure that in MiNT?

I don't think there's any monitoring of that built in, but since IO is
never done in the background (:-(  ), it shouldn't be very hard to add.

Increasing priority based on disk IO statistics don't seem like a very
good idea to me, though.

> >Btw. I tried to link the gcc binaries from /ram, as well as use the
> >-pipe option, and it speeded up the compilation of NcFTP by ~20% :-)

Some years ago, I used ICD's harddisk driver with a relatively large cache
(both read and write) and that was also good for gcc compile times.
You should get most of the ramdisk speed, but using less memory and with
more flexibility.

Unfortunately, I haven't found a HD cache program that will work with
my current machine.
I know minix.fs caches internally, but I've been using TOS-gcc until now,
so I don't really know how effective that is.

On my PC, gcc is very slow without HD cache.
(I don't have SMARTDRV.EXE in my AUTOEXEC.BAT and sometimes boot into DOS...)

> what's /ram? and what is the -pipe option? I need to speed up my compilation

I've not used MiNT-gcc for long, so I've never tried -pipe (it doesn't do
any good under TOS), but if it works like under UNIX (which is likely),
gcc will pipe its output between compilation stages rather than use 
temporary files.

> time - my development cycles are too long (usualy two to five minutes of
> recompiling PARCP or Atari800 - I hate that!)

The best way to cut down on compilation times is to use shorter source files.
After all, most changes/additions are rather local and there's no need to
recompile everything.
I do my best to keep all source files below 20kbyte, by splitting/reorganizing
when needed. IME the extra work needed for this makes the code easier to
maintain in the long run anyway. As an example, the MGIF sources are spread
over more than half a dozen directories, with more than a dozen files in most
of them. Several of those files have been split more than twice.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)