The optimizer could hoist the construct out of the loop...
Assuming it can realize its possible to do that.
Regards,
-- Gregor
On Tue, 2003-10-07 at 01:14, Leopold Toetsch wrote:
> Will Coleda <[EMAIL PROTECTED]> wrote:
> > As I realize my example is incorrect. =-)
>
> > Is there any reason no
Will Coleda <[EMAIL PROTECTED]> wrote:
> As I realize my example is incorrect. =-)
> Is there any reason not to make the ".pcc_call _parse" work also,
> rather than having to construct a .Sub?
We probably could construct a Sub PMC under the hood. The reason for 2
stages is efficiency though: If y
As I realize my example is incorrect. =-)
Is there any reason not to make the ".pcc_call _parse" work also,
rather than having to construct a .Sub?
Regards.
On Monday, October 6, 2003, at 09:19 PM, Will Coleda wrote:
Currently, when calling a PCC Sub with the single Sub (and not with a
Conti
Currently, when calling a PCC Sub with the single Sub (and not with a
Continuation)
.pcc_begin prototyped
.arg $S1
.pcc_call __parse
somerandomlabel:
.result $P1
.pcc_end
Note the label... Every time I call a sub, I need to specify a new,
unique label that I'm very unlikely to ever