memcpy_cpu on 64bit arm

[Michael Grunditz]

On Tue, 24 Jan 2023 at 08:21, Christian Helmuth
<christian.helmuth at genode-labs.com> wrote:
>
> Hello,
>
> On Mon, Jan 23, 2023 at 15:56:48 CET, Michael Grunditz wrote:
> > On Mon, 23 Jan 2023 at 14:15, Michael Grunditz <michael.grunditz at gmail.com> wrote:
> > > Anyway init crashes somewhere.
> > >
> > > 2043 MiB RAM and 64533 caps assigned to init
> > > no RM attachment (READ pf_addr=0x81 pf_ip=0x9f3f4 from pager_object:
> > > pd='init' thread='init')
> > > Warning: page fault, pager_object: pd='init' thread='init' ip=0x9f3f4
> > > fault-addr=0x81 type=no-page
> >
> > I *think* it fails right in start of first child. It seems ok around
> > the starting.
> > The last memcpy seems ok. I have printed both buffers and they are identical.
>
> I'm wondering why you replaced the general memcpy() in the first place
> as this brings maximal (potential negative) impact in many places. You
> could alternatively just optimize your framebuffer blitting and
> proceed with your porting work.

Yes you are absolutely right. I just got a bit excited about what might be
gained.

>
> Also, it is not known which NEON instructions and registers your
> memcpy utilizes. I'm not an ARM expert but: Does the current
> FPU-switching implementation of base-hw suffice or do you need to
> save/restore extended state? As you do not share your developments
> (i.e. source code) with the public it is hard to provide specific
> help.
>

Right again.


> Any information which code is at 0x9f3f4 in ld.lib.so?

No.Sorry. At the top level it crashes
at the first elf starting, init. It seems to be able to start the thread
but fails in the jump ( or something ).

Anyway I will stop doing this little hack. Sorry for sending unwanted email and
thanks for reading!

About the blitting:
I will do benchmarks with and without clipping/flushing.

Also: I want to put things together in a target tree and publish that
on github and at
the same time rebase everything to git level. I think this is the task
I will do first. Things
are scattered across several repos now, and it is quite hard to
handle. I also want to
be open with what I am doing.

Thanks for you patience,

Michae