Dan Sugalski wrote:
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
The big problem with this is you're increasing non-local call
performance for normal running. I don't think this is a good idea--while
you'll save maybe 50
At 10:07 AM +0100 1/30/03, Leopold Toetsch wrote:
Changing the addressing scheme to opcode offsets relative to code
start would simplify all kinds of (non local) control flow changes. As
real world programs mostly consists of such subroutine calls, these
would be simplified a lot (and would then n
Jason Gloudon wrote:
On Sun, Feb 02, 2003 at 12:46:50AM +0100, Leopold Toetsch wrote:
#define IREG(i) interpreter->ctx.int_reg.registers[code_start[offs+i]]
Where does the value of code_start coming from ?
As stated in my first mail in this thread, code_start could be a auto
variable in
On Sun, Feb 02, 2003 at 12:46:50AM +0100, Leopold Toetsch wrote:
> #define IREG(i) interpreter->ctx.int_reg.registers[code_start[offs+i]]
Where does the value of code_start coming from ?
code_start in an opcode function is not a constant, so the above is really:
interpreter->ctx.int_reg.register
Jason Gloudon wrote:
On Thu, Jan 30, 2003 at 10:07:26AM +0100, Leopold Toetsch wrote:
code_start = interpreter->code->base.data; // new syntax
while (offs)
offs = interp->func_table[*(code_start+offs)](offs, ..)
It's unclear to me whether you are saying the opcode functions would sti
On Thu, Jan 30, 2003 at 10:07:26AM +0100, Leopold Toetsch wrote:
> code_start = interpreter->code->base.data; // new syntax
> while (offs)
> offs = interp->func_table[*(code_start+offs)](offs, ..)
It's unclear to me whether you are saying the opcode functions would still be
passed the PC
Leopold Toetsch wrote:
[ mops timings ]
C -O3:277
BTW, same (probably alignment caused) timing diffs (gcc 2.95.2):
$ for i in $(seq 20); do ./mops; done
328.089625 M op/s
319.657445 M op/s
333.533456 M op/s
371.050336 M op/s
345.721672 M op/s
307.465496 M op/s
364.405245 M op/s
330.797305
Steve Fink wrote:
I don't really know a whole lot about this area, but I remember I was
surprised the first time I looked at this and discovered it was based
on pointers instead of offsets. I assumed there was some good reason
for it that I didn't know at the time (eg performance), but now I
doub
I don't really know a whole lot about this area, but I remember I was
surprised the first time I looked at this and discovered it was based
on pointers instead of offsets. I assumed there was some good reason
for it that I didn't know at the time (eg performance), but now I
doubt that. Your way see
or our runloops are wrong
or deep core stuff
All run loops get a pointer to the parrot byte code for execution.
This has several impacts on the runloop itself and on branching and
jumping between instructions.
As parrot PASM jumps are expressed by means of opcodes (absolute or
relative) all ru
10 matches
Mail list logo
