At 8:10 PM -0700 12/1/03, Cory Spencer wrote:
> However, if giving up IMCC's register allocator is worth gaining
the extra control of PASM, by all means do it, however I'm all ears
on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to allow
At 08:10 PM 12/1/2003 -0700, Cory Spencer wrote:
> However, if giving up IMCC's register allocator is worth gaining
> the extra control of PASM, by all means do it, however I'm all ears
> on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to a
> However, if giving up IMCC's register allocator is worth gaining
> the extra control of PASM, by all means do it, however I'm all ears
> on suggestions for IMCC for features. *hint*
In that case, I don't suppose it would be possible for IMCC to allow
function calls in an "if expr goto LABEL" s
;[EMAIL PROTECTED]>
11/29/2003 07:51 AM
To: [EMAIL PROTECTED]
cc:
Subject: Why are .sub and compilation unit one and the same thing?
Am I missing a trick here, thinking it would be better to allow eg:
.imcc
.local int a
.
On Sat, 29 Nov 2003 15:17:11 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
wrote:
>If you have some small specialized subs, you can always put these inside
>.emit/.eom as PASM.
>
I'll ditch imc then and just use pasm for everything,
Thanks,
Pete
Pete Lomax <[EMAIL PROTECTED]> wrote:
ad subject: subroutines are self-contained parts of compiling a program.
They have their own CFG, life analysis and so on. So its the "natural"
way to compile these as units.
> Am I missing a trick here, thinking it would be better to allow eg:
If you have s
Am I missing a trick here, thinking it would be better to allow eg:
.imcc
.local int a
.sub _get_a
return a
.end
.sub _set_a
restore a
.end
.endimcc
