qemu-devel
[Top][All Lists]
Advanced

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

RE: [PATCH] Add minimal Hexagon target - First in a series of patches -


From: Taylor Simpson
Subject: RE: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project and therefore do not conform to qemu coding standards
Date: Thu, 21 Nov 2019 23:51:47 +0000

Hi Aleksandar,

The complete qemu-hexagon implementation can be found here
https://github.com/quic/qemu

From the beginning, I knew I would have to divide it up into smaller patches 
for review.  The discussion on how divide it was here
https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg01971.html

I'll summarize the proposal
    1) linux-user changes + linux-user/hexagon + skeleton of target/hexagon
    2) Add the code this imported from the Hexagon simulator and the qemu 
helper generator
    3) Add support for packet semantics
    4) Add support for wide vector extensions
    5) Add the helper overrides for performance optimization

My assumption in the proposal was that each phase of the submission should 
compile and execute, and each phase should expand the capabilities of the 
Hexagon target.  I apologize that it wasn't clear how large each of the patches 
would be.

I greatly appreciate all of the feedback on the proposal and the patch, and I 
am making the revisions.  In several cases, the feedback also applies to the 
remainder of the code.  So, I am making the changes there as well.  From that 
perspective, I think it will reduce the overall burden on the reviewers.

As far as what might change in the imported files goes, the current simulator 
(hexagon-sim) has been used in production as part of the toolchain for over a 
decade and has been used to verify every version of the core that we have 
shipped.  Since it is used in verification, it is considered the gold standard 
- more so than the PDF manual.  Any changes to that code, including 
reformatting, would put qemu at risk of not accurately emulating the processor.

Taylor


-----Original Message-----
From: Aleksandar Markovic <address@hidden>
Sent: Thursday, November 21, 2019 2:45 PM
To: Taylor Simpson <address@hidden>
Cc: Laurent Vivier <address@hidden>; Riku Voipio <address@hidden>; QEMU 
Developers <address@hidden>
Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of patches 
- linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files 
in target/hexagon/imported are from another project and therefore do not 
conform to qemu coding standards

On Thu, Nov 21, 2019 at 8:52 PM Taylor Simpson <address@hidden> wrote:
>
> They are imported from the existing Hexagon simulator.  Please understand 
> that this patch is the first in a series.  Later patches will contain more 
> elaborate contents in that directory.  The reason I don't want to reformat 
> them is to stay in sync with the other simulator in the future.  When the 
> other team makes changes to the code (either to fix bugs or add features), it 
> will be easier to identify the changes and bring them into qemu.
>
> Taylor
>

Taylor,

Please understand that this patch can't remain a single patch. It can't remain 
even a set of 2 or 3 patches as others suggested. A patch is a logically 
connected unit of code whose typical size is less than
200 lines. There are lots of such logical units in this single path that you 
sent, and you should not have sent it in its present form, even if you wanted 
just comments to it. You should have submitted a series rather than a single 
patch. And you should have said this is v1 of my series that I will expand 
later on. Guidelines for submissions are here:

https://wiki.qemu.org/Contribute/SubmitAPatch

As far as "imported" files, frankly, I dislike the fact that you are willing to 
sacrifice our coding style guidelines in favor to your convenience. But, more 
than this, I also find very problematic that you practically create a 
dependency between QEMU and another simulator. QEMU implementation should rely 
on specifications, and only on specifications, and certainly should not depend 
on another simulator. Currently, in QEMU, there are some cases of imported 
disassemblers or similar relatively unimportant tools, but those imports change 
very rarely, and are modified to comply to QEMU coding style. I am not aware on 
dependency of QEMU on another simulator in the form you want to do for Hexagon. 
My strong impression is that you will create more problems than benefits with 
such dependency, both for you and for QEMU in general.

Once a CPU or any other device is specified though documentation, these specs 
don't change. Consequently, their emulation does not change too, in functional 
sense. The fact that you anticipate changes in these files imported from 
another simulator, leaves me with a (possibly wrong) perception that neither 
Hexagon internal simulator nor QEMU implementation you are trying to integrate 
are complete. If that is not true, can you explain what exactly you expect to 
be changing in imported files?

Yours,
Aleksandar


> -----Original Message-----
> From: Aleksandar Markovic <address@hidden>
> Sent: Thursday, November 21, 2019 1:20 PM
> To: Taylor Simpson <address@hidden>
> Cc: Laurent Vivier <address@hidden>; Riku Voipio
> <address@hidden>; QEMU Developers <address@hidden>
> Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of
> patches - linux-user changes + linux-user/hexagon + skeleton of
> target/hexagon - Files in target/hexagon/imported are from another
> project and therefore do not conform to qemu coding standards
>
>
> >  create mode 100644 target/hexagon/imported/global_types.h
> >  create mode 100644 target/hexagon/imported/iss_ver_registers.h
> >  create mode 100644 target/hexagon/imported/max.h  create mode
> > 100644 target/hexagon/imported/regs.h
>
> Taylor, if I understood you well, these files don't confirm to QEMU coding 
> standard, because they are imported. But, from where? And what is the reason 
> they need to be imported (and not created independently by you or somebody 
> else, but within QEMU code style guidelines) ?
> Their content looks fairly simple to me.
>
> Thanks,
> Aleksandar

reply via email to

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