[libre-riscv-dev] spike-sv non-default element widths

[Jacob Lifshay]

On Wed, Oct 17, 2018, 22:47 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Wed, Oct 17, 2018 at 8:47 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > On Wed, Oct 17, 2018, 05:06 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > https://libre-riscv.org/simple_v_extension/specification/#elwidth
> > >
> > > new section in specification on element widths, including pseudo-code.
> > > comments / thoughts appreciated, am slowly working towards getting
> > > this implemented.
> > >
> > Note that how you've written the reg_t union with pointers in it, using
> the
> > pointers like arrays won't achieve your intended effect, they will
> instead
> > reinterpret the value of the register as the memory address at which to
> > load/store when (I assume) reading/writing from/to the registers.
>
>  there's a trick in c where you can reference pointer as an array.
> the other syntax i believe is uint8_t b[] which may be clearer
>
actually, it's just that array values are implicitly cast to pointers and
the [] operator is defined in terms of pointers.

see https://gcc.godbolt.org/z/oWbmar for why int v[] and int *v are not
interchangable. try replacing the int v[0] with int v[] and you will get a
compile error. Note the -xc command line option is used to switch from c++
to c mode.

>
> > You can
> > use arrays, but that won't work for larger-than-xlen values as that makes
> > the compiler insert padding for alignment purposes.
>
>  i believe uint8_t b[] does the trick, although from my samba /
> DCE/RPC days i am fairly certain that's equivalent to uint8_t *b,
> anyway.
>
It is not equivalent.

> array type declarations are only converted into pointer type declarations
directly in function parameters, everywhere else array type declarations
declare arrays.

>
>  the main thing here for the spec is clarity: keeping the pseudo-code
> down to the bare minimum.  what's there is already way too long.
>
I agree clarity is essential, however correctness is more essential.

Jacob Lifshay