lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unaligned load/store opcodes


From: Paulo César Pereira de Andrade
Subject: Re: Unaligned load/store opcodes
Date: Thu, 6 Apr 2023 08:31:45 -0300

Em qui., 6 de abr. de 2023 às 05:28, Paul Cercueil
<paul@crapouillou.net> escreveu:
>
> Hi Paulo,

  Hi Paul,

> Le mercredi 05 avril 2023 à 13:08 -0300, Paulo César Pereira de Andrade
> a écrit :
> > Em qui., 23 de mar. de 2023 às 08:07, Paul Cercueil
> > <paul@crapouillou.net> escreveu:
> > >
> > > Hi Paulo,
> >
> >   Hi Paul,
> >
> > > I think Lightning would benefit from having support for 16/32/64-
> > > bit
> > > I/O to unaligned addresses. That's something I would actually use.
> > >
> > > Something like:
> > > ldur_s / ldur_us / ldur_i / ldur_ui / ldur_l
> > > stur_s / stur_i / stur_l
> > >
> > > I don't think we need ldx/stx variants.
> >
> >   Please check the new instructions (not yet properly documented):
> >
> > unldr r0 r1 i0 -- r0 = *(signed_i0_size*)r1
> > unldi r0 i1 -- r0 = *(signed_i1_size*)i0
> > unldr_u r0 r1 i0 -- r0 = *(unsigned_i0_size*)r1
> > unldi_u r0 i1 -- r0 = *(unsigned_i1_size*)i0
> > unstr r0 r1 i0 -- *(i0_size_integer*)r0 = r1
> > unsti i0 r0 i1 -- *(i1_size_integer*)r0 = r0
> >
> > valid size values are 1 to wordsize. This means it can help for
> > integers
> > with a size other than 1, 2, 4 or 8.
> >
> > unldr_x r0 r1 i0 -- r0 = *(i0_size_float*)r1
> > unldi_x r0 i0 i1 -- r0 = *(i1_size_float*)i0
> > unstr_x r0 r1 i0 -- *(i0_size_float*)r0 = r1
> > unstr_x i0 r0 i1 -- *(i1_size_float*)i0 = r0
> >
> > valid size values are 4 and 8. There is no plan, but it is possible
> > to
> > add support for soft floats of a size other than 4 or 8. 1 and 2 byte
> > floats could be very useful as a way to use less memory for low
> > precision data, but if ever added, it would be only for load/store,
> > otherwise, would need a conversion to a higher sized value.
> >
> > > What do you think?
> >
> >   It should be in a functional state, but some optimizations can
> > still be
> > done, or some redesign might be done as well.
>
> Just with a quick glance at the MIPS implementation, it looks much more
> complex than it needs to be... You can do a 32-bit (or 64-bit)
> unaligned read with just LWL+LWR (LDL+LDR respectively) then clear or
> sign-extend the bits you're not interested in, I don't see why you need
> a loop and bit shifts for.

  I will rework it. I think I did not properly understand how these instructions
work. Also, I did write fallback/generic for mips 32 bit, then work on the
LDR, LDL on mips 64 big endian, and did not notice it is actually broken
for little endian.

  I will work on getting it working in the next few days.

  I started working on a convenience movi_w_f, movi_w_d and movi_ww_d
to counterpart movi_f_w, movi_d_w and movi_d_ww, and noticed a few
more problems during it; problems editing a file in the real test and not
fully copying back to the actual files under git, but  it should be fixed
shortly.

> I really won't have time for anything before next week, unfortunately.
> I'll give it a proper test then.

  No problems :) Until next week I hope to have fixed the remaining
issues, by running make check in ever port and fixing any issue.

> Cheers,
> -Paul

Thanks!
Paulo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]