[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-mes] mescc and Load/Store architectures
From: |
Jan Nieuwenhuizen |
Subject: |
Re: [bug-mes] mescc and Load/Store architectures |
Date: |
Thu, 07 Feb 2019 20:12:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Danny Milosavljevic writes:
Hi Danny,
> On Thu, 07 Feb 2019 16:08:38 +0100
> Jan Nieuwenhuizen <address@hidden> wrote:
>
>> Jan Nieuwenhuizen writes:
>>
>> Oh, I just realise that whether or not we prototype/use these
>>
>> > (define (armv4:label->arg info label i)
>> > `(("ldr____$i32,%s" (#:address ,label))
>> > ("push___%s)))
>>
>> > (define (armv4:r-mem-add info v)
>> > (let ((r (get-r info)))
>> > `(,(if (< (abs v) #x1000) `(,(string-append "ldr___(%" "r),%s")
>> > ,(string-append "add___$i8,(%" s ")")
>> > (#:immediate1 ,v)
>> > ,(string-append "str___%s,(" r ")"))
>> > `(,(string-append "ldr___(%" "r),%s")
>> > ,(string-append "add____$i32,(%" r ")") (#:immediate ,v)
>> > ,(string-append "str___%s,(" r ")"))))))
>> >
>>
>> for ARM, we can still use the same for x86 and thus keep using the same
>> M1 alphabet across processors. That was probably part of your
>> suggestion, right?
>>
>> That could be a feature, it could even reduce the alphabet specified in
>> x86.M1. Not sure if a performance loss, if any, is relevant.
>
> Yes, that would be ideal.
>
> Nowadays we have to measure the performance loss, the CPUs are too
> complicated for us to tell otherwise. A wild speculation would say
> that CISC CPUs do the same RISC steps internally anyway (in
> microcode), so it shouldn't make a difference, except:
Hah! It's hard to defeat the physics.
> If there are more instructions per program, the instruction cache will
> miss more and be eventually be full. In general probably more loads
> from main memory need to be done, so it *could* be that it's slower
> with more instructions per program compared to the fewer instructions
> per program.
Yes, I can imagine that using more registers and avoiding re-fetching
from memory really helps, but using more registers also means a richer
alphabet in ??.M1, which is currently not really what we want.
I'd gladly see some optimizing work someday in MesCC, could be fun
too ;-)
janneke
--
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com
- [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/07
- Re: [bug-mes] mescc and Load/Store architectures, Jan Nieuwenhuizen, 2019/02/07
- Re: [bug-mes] mescc and Load/Store architectures, Jan Nieuwenhuizen, 2019/02/07
- Re: [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/07
- Re: [bug-mes] mescc and Load/Store architectures,
Jan Nieuwenhuizen <=
- Re: [bug-mes] mescc and Load/Store architectures, Jeremiah, 2019/02/07
- Re: [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/12
- Re: [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/12
- Re: [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/13
Re: [bug-mes] mescc and Load/Store architectures, Danny Milosavljevic, 2019/02/07