Re: [cc65] Zero page, C stack, and interrupts

Apr 27, 2:50 PM: Groepaz <groepaz@gmx.net> wrote:
>
> and then some (long) time later i decided to write my own
> kernel from scratch  <snip>  infact the only thing my "os"
> currently cant do that lunix can is networking, everything else
> works more or less.

Well good sir, why aren't we all using Groenix by now?  I'd like to
give it a whirl myself.  Are your libraries re-entrant?


> > ... I don't think it would be too difficult to
> > come up with libraries that were re-entrant AND could be used
> > efficiently by programs that don't care about other tasks.  But
> > then ...
>
> the problem is, that currently, with non-reentrant runtime, the
> library can cheat a lot at various places, and by that reduce
> codesize (and increase speed) quite a bit. i wouldnt want to
> miss that for code that doesnt require reentrant libs (which
> also is the common case). but indeed, i wouldnt mind reentrant
> libs as an option :)

A fully capable paged memory extension cartridge would REALLY
come in handy for keeping re-entrant libraries fast.  But I
haven't built that quite yet, have I?

I'm curious how much of a speed difference there would be.  I
think I would probably start with a fully reentrant library,
then come up with single-thread versions of just those
functions that could really benefit.

Then I'm not sure if it would be the application's choice on
which to use, or more of a configuration preference of the
user.  If a (well-behaved) app was built against the ST library
and had a fully compatible MT version substituted, it shouldn't
do much more than slow it down.  If you go the other way, then
you'd have a program blocking that didn't expect to.

But then there's the careful use of CS and other semaphores.
If the O/S has good cooperative support, how much would you
REALLY need re-entrant code?  Most non-reentrant calls are
short enough that other processes can block w/o causing
problems.  Those that tie up shared memory for a long time
perhaps wouldn't gain much from all the shortcuts.

I'm really anxious to be working on these issues.  I can only
go so far without actually trying to implement the stuff.


// Steve
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.