Re: [bug-mes] mescc and Load/Store architectures

[Jan Nieuwenhuizen]

Danny Milosavljevic writes:

Hi Danny,

>> It seems that an abstraction is missing or is just in the wrong place,
>> I don't see it very clearly just yet, so I'm open for any suggestions.
>
> Usually, compilers use registers aggressively to avoid stack accesses.
>
> That's why I was not confident to just designate a random register a scratch
> register statically and always use that one.

Okay, we don't want to worry about this.  MesCC is not doing any sort of
optimization so in a way it's more of a transpiler maybe.  Currently
it's only job is bootstrapping tcc, then tcc compiles itself and that is
what we use.  Still, tcc compiles itself very fast (seconds), where
mescc takes minutes to compile tcc.

> That would be an easy solution but it only works if we ensure that
> compiler.scm doesn't scribble all over it and expects us to conserve
> it--and I just don't know enough about compile.scm in mescc to be able
> to choose one.

Sure...in the two examples the scratch register would only be used
very temporarily; if its lifetime needs to be bigger then we must
be careful...however the resulting M1 code is very readable so we
should easily catch that?

>> What if we appoint one scratch register 's' and do something like
>> 
>> --8<---------------cut here---------------start------------->8---
>> (define (armv4:label->arg info label i)
>>   `(("ldr____$i32,%s" (#:address ,label))
>>     ("push___%s)))
>> --8<---------------cut here---------------end--------------->8---
>> 
>> Would that be good enough for (2), 
>
> Yes, although it would be slower than if the compiler remembered which values
> are in which registers and thus avoids the second ldr if possible (if the
> value is already supposed to be loaded in there).

Sure.  Let's not worry about that now?

>>or does the compiler need to know
>> about scratch register `s' and save it in certain cases?
>
> I guess for a bootstrapping compiler that's not necessary, so let's just
> use a fixed scratch register and not save, restore or track its value in
> any way.

Good!

> This
>
>>            `(,(string-append "ldr___(%" "r),%s")
>>              ,(string-append "add____$i32,(%" r ")") (#:immediate ,v)
>>              ,(string-append "str___%s,(" r ")"))))))
>
> ... probably meant this:
>
>>            `(,(string-append "ldr___(%" "r),%s")
>>              ,(string-append "add____$i32,%s") (#:immediate ,v)
>>              ,(string-append "str___%s,(" r ")"))))))

Yes, sure.  Great that you understand me even if I make mistakes :-)

>> Even if this works it could still be a better idea to pull it further
>> into the compiler (compile.scm) where these are used...I'm not sure.
>> WDYT?
>
> It depends on how much we want to optimize for runtime speed (with all
> the usual traps caching causes - cache invalidation, stale cache etc).

Not right now and I don't see that happening any time soon.  I would go
for simplicity (we have a way to go there in ways of mes and mescc...).

Greetings,
janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com