Gregor N. Purdy writes:
> Luke --
> 
> Yeah. That falls into the "duh" category, I guess.
> 
> But, I'm still having some trouble:
> 
> 
> .pcc_sub _consume_string prototyped
>   .param str input

    .param string input

Now the error makes sense.

>   .local int c
>   .local int test
> 
>   .local Sub __char_is_white_space
>   newsub __char_is_white_space, .Sub, _char_is_white_space
> 
>   .local Sub __char_is_digit
>   newsub __char_is_digit, .Sub, _char_is_digit
> 
> CONSUME:
>   ord c, input
>   substr input, input, 1 # error:imcc:op not found 'ord_i_p' (ord<2>)

And I assume here you mean:

    substr input, input, 0, 1

Luke

>   ....
> 
> 
> (Note that the complaint about ord_i_p is on the substr line,
> and its as if it thinks input is a PMC not a string.
> 
> 
> Regards,
> 
> -- Gregor
> 
> On Sun, 2003-10-12 at 12:15, Luke Palmer wrote:
> > Gregor N. Purdy writes:
> > > Leo --
> > > 
> > > The Jako compiler spits stuff out from Perl.
> > > 
> > > I'm writing some new experimental stuff in PIR directly.
> > > 
> > > I'm curious about other stuff, too. I don't see any
> > > of the languages/imcc/t/**/*.t files doing anything with
> > > the ord op, and when I try to use it as
> > > 
> > >   .local int c
> > >   .local str s
> > > 
> > > and then
> > > 
> > >   c = ord(s)
> > > 
> > > or
> > > 
> > >   ord(c, s)
> > > 
> > > in my .imc file, neither works. Do I need to do magic to
> > > use any old op I want?
> > 
> > Uhh... I may be misunderstanding the question, but you should be able to
> > use assembler syntax, eg.
> > 
> >     ord c, s
> > 
> > That works for me.
> > 
> > Luke
> > 
> > > 
> > > Regards,
> > > 
> > > -- Gregor
> > > 
> > > On Sun, 2003-10-12 at 11:42, Leopold Toetsch wrote:
> > > > Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> > > > > Is there any good reason why prototyped PCC subs
> > > > > shouldn't be callable with IMC syntax that looks like
> > > > > a macro call, without having to make a macro wrapper
> > > > > manually?
> > > > 
> > > > Could be done, but for sure unlikely. PASM/PIR are still assembler
> > > > languages. You can stuff features and more into it, but this is not the
> > > > goal. The assembler syntax should be simple and easy to generate from
> > > > HLL compilers. It should of course have support for all the features of
> > > > the underlying CPU (parrot), but not much more.
> > > > You are AFAIK generating PIR files by  perl, so just spit out
> > > > the function call, that's it.
> > > > 
> > > > leo
> > > -- 
> > > Gregor Purdy                            [EMAIL PROTECTED]
> > > Focus Research, Inc.               http://www.focusresearch.com/
> -- 
> Gregor Purdy                            [EMAIL PROTECTED]
> Focus Research, Inc.               http://www.focusresearch.com/

Reply via email to