Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
or address:
inline op bsr (label INT)
label is basically in, additionally there are now labelvar and
labelconst
Leopold Toetsch wrote:
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
3) A flag, if the opcode
Hi,
On Friday 19 March 2004 12:07, Leopold Toetsch wrote:
Some weeks ago I posted a proposal for additional hints in ops files. We
need additionally (at least):
1) a per argument flag, if this argument is indicating a branch offset
or address:
inline op bsr (label INT)
label is
Jens Rieks [EMAIL PROTECTED] wrote:
Hi,
On Friday 19 March 2004 12:07, Leopold Toetsch wrote:
2) Classification of opcodes (s. Safe(3pm), Opcode(3pm). I've just done
a few - only to see if it get parsed correctly. This needs a lot of work
and thought. Any help is much appreciated here.
I
Leopold Toetsch wrote:
We also need a way to mark ops for inclusion in miniparrot's limited op
set--although it might be better to do that in an external file.
Or mark exclusion, which might be simpler.
Simpler, yes. Safer, no.
What ops aren't supposed to
be in miniparrot?
Anything we can't
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
What ops aren't supposed to
be in miniparrot?
Anything we can't guarantee can be supported on any ANSI-compliant
platform with very little to no probing. (Ideally, I'd like for
miniparrot to include no test C
