It's feedback time!

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>Ah well. Looks like there's a reason all those unix workstations have R4000
>or Alpha processors in them then :-). I'll let you know how it works on an
>040 early next year.

Heh...well on UNIX it's a lot simpler, all the library read() does is
call the operating system, which then does the right thing...of course
the internals of the read() call in UNIX are probably pretty hairy
too..

Of course a faster processor doesn't hurt...but from what I hear the
overhead difference in millions of single-byte reads() between a 68000
and an '03 isn't as much as one would hope...

>Yes, I've heard of that. Doesn't it do things like bcopy the entire
>execution space every timeslice though. It sounds *incredibly* slow. At
>least, there ought to be an option for >020 processors.

Exactly.  Sounds slow to me too.  I agree, on processors where it
isn't necessary to fake it it should be done properly.

Just a guess here, but it may be possible to do a non-blocking fork on
a 68000 for shared-text programs without copying the whole thing in
and out.  Whether anyone ever gets around to implementing any of this
is of course still an open question ...

>> What problems have you had with signals?
>
>The error numbers were the annoying ones. There's a list below of what 
>Ultrix defines and what MiNT defines. There's a fair amount of common
>ground, but MiNT appears to 'double-up' its errors, ie: where Ultrix will
>have 2 or 3 errors, MiNT has only the one, which is returned for all 2 or 3
>cases.
>
>The signals are (mainly) annoying because I have problems understanding 
>the function prototype definitions in the header files :-). I think they
>actually map quite well across to unix.

Yeah they are kinda hairy...too bad cdecl doesn't decode ansi
declarations (at least the version I have) and doesn't really deal
with typedefs either...

>The following are defined by Ultrix. I've put the MiNT error numbers in
>brackets after the Ultrix ones. There are other MiNT codes unsupported by
>Ultrix after this list...
>
>

Thanks for the errno list.

>(1) Should be EBUSY ?
>(2) Should be ESPIPE ? (why PIPE ?)
>(3) MiNT defines it to be    /* invalid function number */ 

I'll look into these, i'm not sure offhand...

--entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu