PCC and IMC
Gregor N. Purdy
shouldn't be callable with IMC syntax that looks like
a macro call, without having to make a macro wrapper
manually? (I know its not the way it works now, but
you can almost simulate it with a PCC sub def and a
macro, and it seems to me it would be nice if it was
free instead) It would make code more readable...
.pcc_sub _howdy prototyped
.param str who
print "Hello, "
print str
print "!\n"
.end
...
_howdy("partner")
It would be better still if it could handle at least
single return values, too. It would make the IMC stuff
I'm writing much more readable and easier to write, too...
If that wouldn't be considered a mis-feature, does
anyone have a good feeling for how hard it would be to
adjust the IMC syntax and update the compiler?
Regards,
-- Gregor
--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/
Melvin Smith
of the IMCC syntax. We have incrementally added some
features at different times that could be handled with a more
compact syntax if we rework it.
1) Combine .pcc_sub and .sub and go back to using
the single keyword .sub.
*This means we will have to add extra qualifiers so IMCC
knows what sort of sub it is.
Examples might be:
# Prototyped, continuation calling convention
# Continuation calls (or standard Parrot call as we could call it) should
# probably be the default in absence of the keyword
.sub foo pcall prototyped
# Non-prototyped, standard stack call
.sub bar stdcall
2) Given a subroutine's call convention based on
a) Its prototype
b) The default in absence of a prototype
we should be able to generate whatever specific code
for that calling convention without making the PIR look
much different for each one
3) Keep PIR syntax as simple as possible with as few directives
and features.
We should at least have an on-list discussion about how
the new syntax should look before we rework it.
-Melvin
Leopold Toetsch
> 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 N. Purdy
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?
Regards,
-- Gregor
Luke Palmer
> 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
Gregor N. Purdy
Yeah. That falls into the "duh" category, I guess.
But, I'm still having some trouble:
.pcc_sub _consume_string prototyped
.param str input
.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>)
....
(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
Luke Palmer
> 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
Leopold Toetsch
> .local str s
a lot of problems you have (and Luke already hinted at that) seems to be
the syntax of .sym (or .local) - I prefer .sym because .local is used
for local macro lables too hysterically.
So we have:
.sym int I_REG
.sym float N_REG
.sym string S_REG
.sym any_but_above_3 P_REG
The latter might be to liberate, but it works like that. If that's too
dangerous, we can talk about that:
.sym var
.sym pmc
or such, a short and strict decl of a PMC.
leo