[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69

From: Felix Winkelmann
Subject: Re: [Chicken-hackers] [PATCH(5)] Remove srfi-18 and srfi-69
Date: Fri, 12 Sep 2014 14:22:39 +0200 (CEST)

> My idea has been that we will wrap all internal "functinal blocks" into
> modules, so that we have a uniform way of controlling access and
> immediately see where a particular procedure is used in core. This might
> be tedious or even busy work but I think we could benefit from that.
> I did not intend to make this available to the user of fixate the API in
> any way. We still will be free to change anything at will, but we had a
> couple of bugs where we forgot to include this identifier or the other
> in the declare statements. At least this way you will get the (annoying)
> unbound symbol error / warning when compiling, so I think that's a plus.

Right - I got it now. That makes sense. Wouldn't it be nice if we got rid of all
those "##sys#"'s and "##net#"'s...

> By speaking of the scheduler.scm: There's a foreign-declare statement
> *within* the (declare) clause. Does that work and what does it do?

It includes literal C code directly in the code generated by the compiler.
There are a couple of helper functions and macros in there. You can ignore it,
just leave the foreign-declaration as it is. 

"disable-interrupts" is needed to avoid context-switches inside the
scheduler code. "unsafe" squeezes out a bit more speed. The "not
inline" declaration for ##sys#interrupt-hook is needed to avoid that
the compiler inlines calls to this procedure (this may not be
necessary here, but since it is a hook function, we don't want the
compiler to make now (or in future) any assumptions about optimizing
accesses to it. Consider this the equivalent of a "volatile" declaration
in C.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]