From: "Michael S. Zick" <mszick@goquest.com>
To: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] uninline in bitops.c as ia64 or sparc64?
Date: Mon, 9 Aug 2004 12:15:30 -0500 [thread overview]
Message-ID: <200408091215.30941.mszick@goquest.com> (raw)
In-Reply-To: <200408090954.08340.mszick@goquest.com>
On Mon August 9 2004 09:54, Michael S. Zick wrote:
>
-------
>
> Mike
>
> Index: include/asm-parisc/bitops.h
> ===================================================================
> RCS file: /opt/lib/cvs/parisc/include/asm-parisc/bitops.h,v
> retrieving revision 1.1.1.1
> diff -u -3 -p -r1.1.1.1 bitops.h
Sorry for the self-reply...
If compiled with 32-bit compiler the NOT(__LP64__) path will compile.
If the resultant program is loaded on a 64-bit machine running 'narrow mode';
it will fail. Since the mode bit only changes the addressing not the
bit-position numbering.(1)
Translation:
As submitted, it should compile for 64-bit and run 64-Wide;
it should compile for 32-bit and run 32-bit.
It is only the case of compiling for 32-bit and then trying to
run it on a 64-bit machine in narrow mode that should fail.
I'll work on this - I probably will abuse the shift-right-double
instruction to come up with a compiles correctly, runs anywhere
version.
Two other problems I am considering:
1) It only beats on two (not counting GR0) registers;
it will probably cause register stalls on pipelined machines.
2) It is bigger than a cache line, probably executes in less
than a memory cycle - so it will probably 'starve' the cpu;
waiting for the next memory cycle to fill the next i-cache line.
Taken all together - an interesting problem.
Mike
(1) Does 32-bit gcc ever generate extract/deposit? This might
cause problems running anything 32-bit on 64-bit-narrow.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2004-08-09 17:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-06 19:22 [parisc-linux] uniline ? Joel Soete
[not found] ` <200407310929.29022.mszick@goquest.com>
[not found] ` <1091293141.1920.34.camel@mulgrave>
2004-08-09 14:54 ` [parisc-linux] uninline in bitops.c as ia64 or sparc64? Michael S. Zick
2004-08-09 17:15 ` Michael S. Zick [this message]
[not found] <200408101145.20933.mszick@goquest.com>
2004-08-11 11:58 ` Joel Soete
2004-08-12 13:59 ` Michael S. Zick
2004-08-13 18:15 ` Michael S. Zick
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=200408091215.30941.mszick@goquest.com \
--to=mszick@goquest.com \
--cc=parisc-linux@lists.parisc-linux.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