public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Pete Batard <pete@akeo.ie>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Gao, Liming" <liming.gao@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 0/4] Add ARM64 support for VS2017
Date: Fri, 16 Mar 2018 11:03:39 +0000	[thread overview]
Message-ID: <cda59a53-09fe-982e-6c70-7dd36bf7af81@akeo.ie> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E1E7EEB@SHSMSX104.ccr.corp.intel.com>

On 2018.03.16 08:24, Gao, Liming wrote:
> Pete:
>     .S for GCC assembly, .asm for MSFT assembly. They can have the different comment style.

Yes, but as I explained, the actual original issue is that our current 
.S files do *not* have the same comment styles in the first place.

If you look at MdePkg/Library/BaseLib/AArch64/SwitchStack.S, you'll see 
that is uses '//' for comments, whereas other .S files, such as 
MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S, use '#'.

So that is our actual issue here: Regardless of VS2017, the GCC assembly 
files for AARCH64 we currently have do not use the same comment style.

Thus, the only reason why the .asm don't have the same comment style in 
our proposal is because the .S, which we derived the .asm from, don't. 
This means that either we should fix the .S too, or we shouldn't fix 
anything at all.

>    Here, my comment is to make sure .asm files have the same comment style. I don't request to change .S file.

And what I am saying is that it makes little sense to harmonize the 
comment style for the .asm files, if we're not going to do the same for 
the .S files as well. It just doesn't seem fair in my book to have the 
VS2017 assembly files held to a higher standard than the GCC ones. So 
either we need to fix both, or we fix none at all.

But as I indicated in my last e-mail, I am planning to send an 
additional patch that does comment harmonization, for both .S and .asm, 
*after* this VS2017 series has been applied to mainline. So the change 
you request will happen. Just not as part of this patch series.

And the reason I have insist on splitting these changes is because, if 
we have to alter the .S files to be consistent, then this comment 
harmonization request should logically be handled separately from the 
VS2017 effort.

Please let me know if you still think having a future separate patch, 
that will do .S and .asm comment harmonization, does not make sense.

Regards,

/Pete

> 
>> -----Original Message-----
>> From: Pete Batard [mailto:pete@akeo.ie]
>> Sent: Thursday, March 15, 2018 5:28 PM
>> To: Gao, Liming <liming.gao@intel.com>; edk2-devel@lists.01.org
>> Cc: ard.biesheuvel@linaro.org
>> Subject: Re: [PATCH 0/4] Add ARM64 support for VS2017
>>
>> Hi Liming,
>>
>> Thanks for reviewing the patches.
>>
>> On 2018.03.15 06:15, Gao, Liming wrote:
>>> Pete:
>>>     For new added ASM file in BaseLib, could you use the same comment style
>>> for them? ASM use ; for the comment. Most of new files uses ; as the
>>> comment, but switchstack is not.
>>
>> This is because SwitchStack.asm is simply SwitchStack.S, with the GCC
>> assembler specifics removed, and MSVC assembler specifics added.
>>
>> I did not change the comment style from the original files, so the real
>> issue here is that our GCC assembly files for AARCH64 do not use the
>> same comment style.
>>
>> I'm fine with trying to harmonize the comment styles, but seeing as this
>> needs to be done for both the .S and .asm, I'd rather send a patch to do
>> that *after* these VS2017 changes have been applied, as I don't consider
>> this correction to in scope of this patch series (because logically, the
>> introduction of VS2017 should not alter any of the .S files, unless we
>> reuse them, which we don't).
>>
>> If you agree to apply this series, I'll make sure to send a non
>> VS2017-specific additional patch, that does what you request for both
>> the .S and .asm.
>>
>>> Besides, compared to Arm arch assembly
>>> file, I don't find CpuPause.asm. Is it required?
>>
>> That file doesn't exist for GCC (as you will see there is no
>> MdePkg/Library/BaseLib/AArch64/CpuPause.S), so we don't have one for
>> VS2017 either.
>>
>> Regards,
>>
>> /Pete



  reply	other threads:[~2018-03-16 10:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23  9:49 [PATCH 0/4] Add ARM64 support for VS2017 Pete Batard
2018-02-23  9:50 ` [PATCH 1/4] MdePkg: Disable some Level 4 warnings for VS2017/ARM64 Pete Batard
2018-02-23  9:50 ` [PATCH 2/4] MdePkg/Library/BaseLib: Enable VS2017/ARM64 builds Pete Batard
2018-02-23  9:50 ` [PATCH 3/4] MdePkg/Include: Add VA list support for VS2017/ARM64 Pete Batard
2018-02-23  9:50 ` [PATCH 4/4] BaseTools/Conf: Add VS2017/ARM64 support Pete Batard
2018-02-23 11:55 ` [PATCH 0/4] Add ARM64 support for VS2017 Ard Biesheuvel
2018-02-23 13:14   ` Pete Batard
2018-03-15  6:15 ` Gao, Liming
2018-03-15  9:28   ` Pete Batard
2018-03-16  8:24     ` Gao, Liming
2018-03-16 11:03       ` Pete Batard [this message]
2018-03-16 15:56         ` Gao, Liming
2018-03-16 16:11           ` Pete Batard
2018-03-16 16:31             ` Gao, Liming
2018-03-16 16:35               ` Pete Batard
2018-03-19  9:07                 ` Gao, Liming
  -- strict thread matches above, loose matches on Subject: below --
2018-02-14 13:08 Pete Batard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cda59a53-09fe-982e-6c70-7dd36bf7af81@akeo.ie \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox