[gem5-dev] Re: vector register indexing modes and renaming?

[Giacomo Travaglini via gem5-dev]

> -----Original Message-----
> From: Gabe Black <gabe.bl...@gmail.com>
> Sent: 24 February 2021 15:24
> To: Giacomo Travaglini <giacomo.travagl...@arm.com>
> Cc: gem5 Developer List <gem5-dev@gem5.org>
> Subject: Re: [gem5-dev] vector register indexing modes and renaming?
>
> So, I started really diving into the interfaces in ThreadContext and 
> ExecContext
> and their various implementations. What I wanted to do was to define a much
> narrower set of maybe 3 virtual functions that actually implements the core of
> what's needed, and not 15-20 different independent virtual methods that all
> need to be reimplemented every time. *That* was quite the rabbit hole, and
> after a number of hours I decided I needed to regroup and come at it from
> another angle. It definitely looks to me like somebody came in with the idea 
> to
> represent these registers using a data, model, view architecture (or something
> like that) which would make sense in other contexts with other types of data,
> but here I don't think is really the right way to go about this.
>
> Right now, I have two questions for you.
>
> 1. Are there tests which exercise this stuff? If I start chopping things up, I
> would be a lot more comfortable if I can tell if/when I break something.

I will ask within Arm if there's something we can provide to you.
In the meantime I gave a quick look at NEON enabled libraries [1]; the Ne10 
library provides a set of functions optimized for NEON  and a set
of examples making use of it [2] (e.g FIR filter, GEMM etc etc).

You could probably cross-compile those examples and use them in SE mode 
(recommending to use the O3 model)

> 2. What's the difference between a lane and an element? Those terms seem
> like they should be synonyms and are treated as almost the same thing, but
> there is clearly a difference between them. What is it, and why does it exist?
>
> Gabe
>

I have the hunch the vector lane logic it's not really used.
My understanding is that Lane/Elem differ in the O3 model only.
The key point is that VecRegister and VecElems are represented by a different 
set of physical registers; you cannot access a vector element if the renaming 
is set to Full[3]; the physical vector register file will be made of valid 
entries, while the vector element register file will be empty. The vector lane 
getters/setters are probably a way to do a functional read of the element 
anyway [4].
In a way we could think of VecReg/VecElem as being the interface to the vector 
file for a guest instruction, while the VecLane to be the interface for the 
host (even though it could be used by an instruction as well)

This is my interpretation of the VecLane

Kind Regards

Giacomo

[1]: https://developer.arm.com/architectures/instruction-sets/simd-isas/neon
[2]: https://github.com/projectNe10/Ne10/tree/master/samples
[3]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/rename_map.hh#L282
[4]: https://github.com/gem5/gem5/blob/stable/src/cpu/o3/regfile.hh#L229

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s