Ops file hints
Leopold Toetsch
1) If an INT argument refers to a label/branch destination
2) For the event-checking code
3) For the safe run core
ad 1) e.g.
inline op eq(in INT, in INT, inconst INT) {
inline op eq(in INT, in INT, in_branch_const INT) {
The C<in_branch_const> translates during ops file mangling to C<inconst>
*and* sets an appropriate flag in OpLib/core.pm, which is carried on
into the op_info structure.
Currently imcc just estimates, if an opcode would branch and where the
label is, which is bad (and error prone) - or more precisley, branching
ops are known, but not all have an associated label.
ad 2) e.g.
op event invoke()
op event_after sleep()
would mean to check at or after that opcode, if events are to be
handled. This would be a flag (or 2) in the op_info.
ad 3)
The safe run-core will very likely need to disallow opcodes per category
similar as in "perldoc Opcode".
e.g.
op :base_io print(...)
Comments welcome (and takers, if we agree)
leo
Dan Sugalski
>IMHO we need some more information in the ops files:
>1) If an INT argument refers to a label/branch destination
>2) For the event-checking code
>3) For the safe run core
>
>ad 1) e.g.
>inline op eq(in INT, in INT, inconst INT) {
>inline op eq(in INT, in INT, in_branch_const INT) {
Works, go for it.
>ad 2) e.g.
>op event invoke()
>op event_after sleep()
>would mean to check at or after that opcode, if events are to be
>handled. This would be a flag (or 2) in the op_info.
Works as well. (Though we need to change sleep to wait on an event to
wake up, but that's separate)
>ad 3)
>The safe run-core will very likely need to disallow opcodes per
>category similar as in "perldoc Opcode".
Yep.
I'd also like to have the ability to add in some other parameters to
the ops file, so if when we're digging in we could wedge in callouts
that by default are ignored, that'd be great.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> Works as well. (Though we need to change sleep to wait on an event to
> wake up, but that's separate)
I thought so too. Its mainly a workaround until we have all the events
done, albeit a plain sleep should be easy.
> I'd also like to have the ability to add in some other parameters to
> the ops file, so if when we're digging in we could wedge in callouts
> that by default are ignored, that'd be great.
Takers wanted. Its mainly a Perl task mangling the ops files.
If more info is needed, please just ask.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
> > I'd also like to have the ability to add in some other parameters to
>> the ops file, so if when we're digging in we could wedge in callouts
>> that by default are ignored, that'd be great.
>
>Takers wanted. Its mainly a Perl task mangling the ops files.
>If more info is needed, please just ask.
As you probably noticed, I threw a bug/todo item in for this. :)