From: Arthur Norman <acn1@ca...> - 2010-09-20 10:30:30
I just checked in a file packages/support/smacros.red with a LOAD of
things from elsewhere on the sources as smacros. This provides an effect
that these get compiled in-line. The downside is that if anybody changes a
function elsewhere then they may want to update the smacro version too.
On CSL (on 64-bit Linux) I think I see this giving about a 4% speedup.
If this gives pain in any way just copy packages/support/smacros0.red to
where smacros.red is - it is an empty version. Then you can rebuild the
system in a safer state.
I also put a load of comments in packages/rlisp/smacro.red to the effect
that the current implementation of the smacro mechanism is a slighly odd
mix between in-line functions and textual expansion - and that there are
pitfalls for the unwary. A discussion or suggestions about ways to
rationalise - or to the effect that we do not need to - would be welcome.
From: Arthur Norman <acn1@ca...> - 2013-03-26 12:35:50
The existing "smacro" scheme has a number of problems - among them the
issue that a macro defined in one package can not be used in another
unless the first package is available at the time the second is compiled.
To work towards a scheme that is more flexible (and also with luck safer)
I am introducing a new keyword "inline" so that
symbolic inline procedure f(a, b); ...
should behave like an ordinary procedure except that when the build system
manages to see it at compile time the function will be compiled in-line
for higher performance.
At present in fact "inline" should just behave exactly as smacro does, but
when I have that stable I will look to make it define a regular function
(callable from anywhere) in addition to recording information that can be
used to expand calls inline. I also hope to change build sequences to
auto-inline many small functions.
Introducing this has involved altering many files to change "smacro" to
"inline", and the extent of changes may look alarming. And I may have
messed some things up! Some cases need to remain as smacros:
(1) if the expansion assigns to one of its arguments,
(2) if the body of the smacro has variables that are free in it but are
(3) if the macro only evaluates its argument conditionally, or evaluates
it within a local scope.
All those cases arise at least once, so some things have been left as
"smacro". The file rlisp/smacro.red has more commentary.
The tests all seem to run OK for me... but if I have messed things up
Get latest updates about Open Source Projects, Conferences and News.