On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> Actually the ops=>C conversion was conceived to do exactly what's being
> done now--to abstract out the body of the opcodes so that they could be
> turned into a switch, or turned into generated machine code, or TIL'd. If
> you're finding that this isn't working well it's a sign we need to change
> things some so they will. (Better now than in six months...)
The problem is that the conversion currently done by process_opcodes.pl
translates the op definitions into functions, and leaves the remainder
of the file untouched. This is useful, because it allows the opcode
file to include headers, declare file-scope variables, and the like.
Unfortunately, when translating the ops into a switch statement in a
header file, there is no place to put this non-opcode code.
There are a few approaches we can take. The simplest, I think, is to
ignore the problem when generating inline ops; given that these ops
are going to be compiled at Perl build time (they can never be
dynamically loaded for obvious reasons), we can manually put any
required #includes in interpreter.c. Files containing dynamically-
loaded ops can be generated in the same way that process_opcodes.pl
does now, preserving the file-scope code.
Another approach would be to include a means of defining information
that must be included by the file implementing the ops. For example:
HEADER {
#include <math.h>
}
This would then be placed into interp_guts.h. (Possibly surrounded
by a conditional guard (#ifdef PARROT_OP_IMPLEMENTATION), so no file
other than interpreter.h will pick up that code.)
- Damien
