[aarch64-port-dev ] RFR (M) 8228400: Remove built-in AArch64 simulator

[Dmitry Samersoff]

Andrew,

Thank you for the explanation. I see your point and OK to leave it as is.

Aleksey, could you add a comment, explaining that number_of_arguments
parameter is no longer used and we keep it here just to maintain x86
compatibility?

-Dmitry\S

On 29.07.2019 11:54, Andrew Dinn wrote:
> On 28/07/2019 21:03, Aleksey Shipilev wrote:
>> On 7/28/19 6:52 PM, Dmitry Samersoff wrote:
>>> 1. Do I understand correctly that we no longer use number_of_arguments
>>> parameter?
>>
>> Yes, I think so.
> 
> Yes we don't need to use this parameter. Indeed we could probably change
> the signature to match the fact that we never supply an argument for it.
> However, ... The reason it is declared in the Aarch64 code is because it
> mirrors the code for x86_64. The argument is not needed for x86_64
> either but the code is dual purpose for x86_32 where the number of
> parameters is needed. So, by dropping this parameter we would be
> choosing to diverge from x86_64.
> 
> I'm not sure how much virtue there is in doing that. When we first
> ported the x86_64 code to Aarch64 we tried to keep the code for the two
> ports aligned as far as possible (i.e. only diverge when the
> architecture and/or performance required it). n.b. that's much the same
> tactic as is adopted when backporting and happens for much the same
> reasons -- many innovations happen first in x86, hence need /cross/
> porting to AArch64.
> 
> This policy has occasionally led to minor oddities like this one but it
> has also made development and maintenance much easier. Diverging on this
> specific point probably wouldn't matter too much one way or the other.
> So long as whoever is maintaining the code knows that it is derived from
> x86_64 they can easily make allowance such a minor differences. However,
> it gets more and more difficult to port code as these sort of changes
> accumulate. Personally, I would prefer to keep the two ports aligned as
> far as possible because my experience is that it has made it a lot
> easier to avoid errors and spot defects. i.e. I think it is a benefit
> rather than a problem that maintainers really need to keep that
> alignment in mind.
> 
>>> Should we remove it and version of call_VM_leaf on l. 1430
>>
>> Maybe? I would leave it as follow-up. The change would be local and easy to test separately.
>> Unfortunately, it would invalidate lots of testing already done for this patch. I can see how much
>> hassle that would be, and maybe fold that improvement here...
> 
> See above. However, Aleksey is right that this should be done as a
> follow-up patch if at all.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>