From: timur@codeaurora.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] [v4] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc
Date: Tue, 18 Aug 2015 14:07:09 -0500 [thread overview]
Message-ID: <55D3825D.6020105@codeaurora.org> (raw)
In-Reply-To: <20150818082141.GA6281@e103592.cambridge.arm.com>
On 08/18/2015 03:21 AM, Dave Martin wrote:
>> Do you think that I need an explicit instruction to clear the upper
>> >bits? I tried a few compiler tricks (e.g. "c && 0xff" and the
>> >like), and they had no effect.
> The in-register representation of a char permits the upper bits to be
> nonzero, so you need to convert to a register-sized type if you want
> to be able to force those bits to zero.
>
> Try: (unsigned long)(unsigned char)c or (unsigned long)c & 0xff.
I tried all those, and more, and I still always get the same thing:
28: 38401423 ldrb w3, [x1],#1
2c: d5130503 msr dbgdtrrx_el0, x3
I know that ldrb will zero-extend the byte to a 32-bit word. But I
don't see any way to zero-extend the word into a 64-bit register.
I'm not even sure that this is necessary. The dbgdtrrx_el0 register is
technically only 32-bit anyway. It looks to me like the code is already
correct.
I could change the (c) to "(c && 0xff)" to be extra sure, but I can't
verify that it actually works.
>> >it gives this assembly code:
>> >
>> > 28: 38401423 ldrb w3, [x1],#1
>> > 2c: 53001c63 uxtb w3, w3
>> > 30: d5130503 msr dbgdtrrx_el0, x3
>> >
>> >Is this correct? Shouldn't it be "uxtb x3, w3"?
> Check the ARM ARM for what operand combinations are allowed. However,
> it doesn't really make any difference here because it's a general rule
> in the architecture that when an instruction's output is in a
> W-register, the upper 32 bits of the corresponding X-register are
> always zeroed anyway.
So does that mean that ldrb will zero-extend the byte to all 64 bits of x3?
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2015-08-18 19:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-08 0:16 [PATCH 1/3] [v2] hvc_dcc: don't ignore errors during initialization Timur Tabi
2015-08-08 0:16 ` [PATCH 2/3] [v4] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc Timur Tabi
2015-08-10 9:40 ` Will Deacon
2015-08-17 23:56 ` Timur Tabi
2015-08-18 8:21 ` Dave Martin
2015-08-18 19:07 ` Timur Tabi [this message]
2015-08-19 10:14 ` Dave Martin
2015-08-19 16:16 ` Timur Tabi
2015-08-19 16:37 ` Dave Martin
2015-08-24 23:51 ` sboyd at codeaurora.org
2015-09-02 11:10 ` Dave Martin
2015-08-08 0:16 ` [PATCH 3/3] [v2] hvc_dcc: disable user-space access to DCC Timur Tabi
2015-08-10 9:47 ` Will Deacon
2015-08-17 22:45 ` Timur Tabi
2015-08-10 9:48 ` [PATCH 1/3] [v2] hvc_dcc: don't ignore errors during initialization Will Deacon
2015-08-19 22:51 ` Timur Tabi
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-all 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=55D3825D.6020105@codeaurora.org \
--to=timur@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).