From: Dave Kleikamp <dave.kleikamp@oracle.com>
To: sparclinux@vger.kernel.org
Subject: Re: [PATCH V3 2/3] Implement byte-by-byte memory access facilitators
Date: Mon, 25 Apr 2016 21:57:17 +0000 [thread overview]
Message-ID: <571E92BD.5050407@oracle.com> (raw)
In-Reply-To: <1461608888-5063-3-git-send-email-dave.kleikamp@oracle.com>
On 04/25/2016 03:48 PM, Sam Ravnborg wrote:
> Hi Dave.
>
>> Sparc64 requires type-aligned memory access. Since data buffers may not
>> be properly aligned, implement a safe copy from memory per data type.
>>
>> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
>> ---
>> defs.h | 41 +++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 41 insertions(+), 0 deletions(-)
>>
>> diff --git a/defs.h b/defs.h
>> index e3afc58..d9d4559 100644
>> --- a/defs.h
>> +++ b/defs.h
>> @@ -2187,6 +2187,45 @@ struct builtin_debug_table {
>> * Facilitators for pulling correctly-sized data out of a buffer at a
>> * known address.
>> */
>> +
>> +#ifdef NEED_ALIGNED_MEM_ACCESS
>> +
>> +#define DEF_LOADER(TYPE) \
>> +static inline TYPE \
>> +load_##TYPE (char *addr) \
>> +{ \
>> + TYPE ret; \
>> + size_t i = sizeof(TYPE); \
>> + while (i--) \
>> + ((char *)&ret)[i] = addr[i]; \
>> + return ret; \
>> +}
>> +
>> +DEF_LOADER(int);
>> +DEF_LOADER(uint);
>> +DEF_LOADER(long);
>> +DEF_LOADER(ulong);
>> +DEF_LOADER(ulonglong);
>> +DEF_LOADER(ushort);
>> +DEF_LOADER(short);
>> +typedef void *pointer_t;
>> +DEF_LOADER(pointer_t);
>> +
>> +#define LOADER(TYPE) load_##TYPE
> A simpler model would be
> #define LOADER(TYPE, addr) \
> ({ \
> TYPE ret; \
> memcpy(&ret, (void *)addr, sizeof(TYPE)); \
> ret; \
> })
This does simplify things a bit.
>
> I would expect the compiler to optimize this away for archs
> that do not require aligned access.
I hesitate to to replace the macros for every architecture with this.
I'll let Dave A. make that call, but I think it can improve the
NEED_ALIGNED_MEM_ACCESS case.
>
> Quick test:
>
> #include <string.h>
> #include <stdio.h>
>
> #define LOADER(TYPE, addr) \
> ({ \
> TYPE ret; \
> memcpy(&ret, (void*)addr, sizeof(TYPE)); \
> ret; \
> })
>
> #define INT(ADDR) LOADER(int, ADDR)
>
> void main(void)
> {
> int i = 37;
> int j = -17;
>
> printf("i=%d j=%d\n", INT(&i), INT(&j));
> }
>
>
> Sam
>
next prev parent reply other threads:[~2016-04-25 21:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-25 18:28 [PATCH V3 2/3] Implement byte-by-byte memory access facilitators Dave Kleikamp
2016-04-25 20:48 ` Sam Ravnborg
2016-04-25 21:57 ` Dave Kleikamp [this message]
2016-04-26 2:46 ` David Miller
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=571E92BD.5050407@oracle.com \
--to=dave.kleikamp@oracle.com \
--cc=sparclinux@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.