Hi!
On Thu, Apr 30, 2020 at 02:48:18PM +0200, FRÉDÉRIC RECOULES wrote:
> I am looking for some clarification about how are working the memory
> operands, especially when the constraint allows memory only (eg. "m").
> Please note that in a lesser extent, I know (by looking the gcc sources) how
>
Hi everyone,
I am looking for some clarification about how are working the memory operands,
especially when the constraint allows memory only (eg. "m").
Please note that in a lesser extent, I know (by looking the gcc sources) how
the things are currently working but I wonder if it is a design
On 18/06/2019 at 00:05, Jeff Law wrote:
If you're going to insist on doing this with an ASM you're likely going
to need to only use registers and constants for constraints since
otherwise you run the risk of getting a stack address.
Thanks for all your clarifications and suggestions.
To optim
On Wed, Jun 19, 2019 at 03:09:08PM +0200, Florian Weimer wrote:
> * Segher Boessenkool:
>
> >> <__GI___getdents64>:
> >>0: addis r2,r12,0
> >> 0: R_PPC64_REL16_HA .TOC.
> >>4: addir2,r2,0
> >> 4: R_PPC64_REL16_L
* Segher Boessenkool:
>> <__GI___getdents64>:
>>0: addis r2,r12,0
>> 0: R_PPC64_REL16_HA .TOC.
>>4: addir2,r2,0
>> 4: R_PPC64_REL16_LO .TOC.+0x4
>>8: li r0,202
>>c: sc
>> 10: mfcr
On Tue, Jun 18, 2019 at 12:19:51PM +0200, Florian Weimer wrote:
> For example, on POWER, the condition register is used to indicate
> errors. Instead of using that directly, we need to store that in a
> register, via mfcr:
Hrm, that example shows that my suggestion in
https://gcc.gnu.org/ml/gcc/2
* Jeff Law:
> This is best addressed by changing GCC itself to know about the
> different ABIs. Trying to tackle in ASMs is going to be painful,
> particularly since your asms change the stack pointer and that's
> generally verboten for an ASM.
Standard practice is to use generic assembler tramp
On Mon, Jun 17, 2019 at 04:05:57PM -0600, Jeff Law wrote:
> On 6/17/19 2:28 PM, Vincent Rivière wrote:
> So what you have here is two different ABIs that have to coexist together?
In a way. He want to define something to do syscalls, which you could
view as a separate ABI yes.
> This is best add
Hi!
On Mon, Jun 17, 2019 at 10:28:37PM +0200, Vincent Rivière wrote:
> My goal is to create optimal C bindings for Atari ST system calls, using
> m68k-elf-gcc (tested with version 7.1.0). Basically, system calls are
> similar to function calls: parameters are stacked in the reverse order,
> las
On 6/17/19 2:28 PM, Vincent Rivière wrote:
> Hi,
>
> My goal is to create optimal C bindings for Atari ST system calls, using
> m68k-elf-gcc (tested with version 7.1.0). Basically, system calls are
> similar to function calls: parameters are stacked in the reverse order,
> last one being a functio
Hi,
My goal is to create optimal C bindings for Atari ST system calls, using
m68k-elf-gcc (tested with version 7.1.0). Basically, system calls are
similar to function calls: parameters are stacked in the reverse order, last
one being a function number. But there are 2 differences from standard
ard_regs; reg != NULL; reg = reg->next)
if (reg->type == OP_OUT && reg->early_clobber && ! reg->subreg_p)
> -Original Message-
> From: Steve Ellcey
> Sent: 05 September 2014 22:49
> To: Vladimir Makarov
> Cc: Robert Suchanek
> Subject: Re
I was wondering if anyone has seen this bug involving LRA and inline
assembly code. On MIPS, I am getting the attached ICE. Somehow
the 'first' pointer in the live_reload_and_inheritance_pseudos bitmap
structure is either getting clobbered or is not being correctly
initialized to begi
On 20 February 2014 12:59, Ramana Radhakrishnan
wrote:
> It's not really because GAS supports it, but there exists a large body
> of code out there which uses inline assembler with pre-UAL syntax. I'm
> not sure people will appreciate a blanket break in one version of the
> toolchain and especiall
On Wed, Feb 19, 2014 at 11:26 PM, Renato Golin wrote:
> On 19 February 2014 23:19, Andrew Pinski wrote:
>> With the unified assembly format, you should not need those
>> .arm/.thumb and in fact emitting them can make things even worse.
>
> If only we could get rid or all pr
. Saleem, is the problem that this is being rejected
>>> earlier?
>>
>> Hi Andrew, Richard,
>>
>> Thanks for your reviews! We agree that we should actually just ignore
>> the contents until object emission.
>>
>> Just for context, one of the reasons wh
) assumption that most inline assembler is written in ARM state.
We went one step further (possibly unnecessarily) and we check what's
the current state before going into inline asm and always emit the
correct code directive afterwards.
We're changing it back from the bad decision to v
y time though. Saleem, is the problem that this is being rejected
>>> earlier?
>>
>> Hi Andrew, Richard,
>>
>> Thanks for your reviews! We agree that we should actually just ignore
>> the contents until object emission.
>>
>> Just for context, one o
On 19 February 2014 23:19, Andrew Pinski wrote:
> With the unified assembly format, you should not need those
> .arm/.thumb and in fact emitting them can make things even worse.
If only we could get rid or all pre-UAL inline assembly on the planet... :)
The has been the only reason why we
rlier?
>
> Hi Andrew, Richard,
>
> Thanks for your reviews! We agree that we should actually just ignore
> the contents until object emission.
>
> Just for context, one of the reasons why we enabled inline assembly
> checks is for some obscure cases when the snippet changes
actually just ignore
the contents until object emission.
Just for context, one of the reasons why we enabled inline assembly
checks is for some obscure cases when the snippet changes the
instructions set (arm -> thumb) and the rest of the function becomes
garbage. Our initial implementation w
Andrew Pinski writes:
> On Tue, Feb 18, 2014 at 6:56 PM, Saleem Abdulrasool
> wrote:
>> Hello.
>>
>> I am sending this at the behest of Renato. I have been working on the ARM
>> integrated assembler in LLVM and came across an interesting item in the Linux
>> kernel.
>>
>> I am wondering if this
On Tue, Feb 18, 2014 at 6:56 PM, Saleem Abdulrasool
wrote:
> Hello.
>
> I am sending this at the behest of Renato. I have been working on the ARM
> integrated assembler in LLVM and came across an interesting item in the Linux
> kernel.
>
> I am wondering if this is an unstated covenant between th
Hello.
I am sending this at the behest of Renato. I have been working on the ARM
integrated assembler in LLVM and came across an interesting item in the Linux
kernel.
I am wondering if this is an unstated covenant between the kernel and GCC or
simply a clever use of an unintended/undefined behav
reed kotler writes:
> For extended inline assembly, there are constraints. Some seem to be
> supported by all architectures and some specific to a particular
> architecture.
>
> Where are these defined in gcc source?
>
> Some seem to be in constraints.md and some n
For extended inline assembly, there are constraints. Some seem to be
supported by all architectures and some specific to a particular
architecture.
Where are these defined in gcc source?
Some seem to be in constraints.md and some not.
Tia.
Reed
roy rosen writes:
> 2011/3/24 Ian Lance Taylor :
>> roy rosen writes:
>>
You build a RECORD_TYPE holding the fields you want to return. You
define the appropriate builtin functions to return that record type.
>>>
>>> How is that done? using define_insn? How do I tell it to return a st
2011/3/24 Ian Lance Taylor :
> roy rosen writes:
>
>>> You build a RECORD_TYPE holding the fields you want to return. You
>>> define the appropriate builtin functions to return that record type.
>>
>> How is that done? using define_insn? How do I tell it to return a struct?
>> Is there an example
roy rosen writes:
>> You build a RECORD_TYPE holding the fields you want to return. You
>> define the appropriate builtin functions to return that record type.
>
> How is that done? using define_insn? How do I tell it to return a struct?
> Is there an example I can look at?
A RECORD_TYPE is wha
2011/3/22 Ian Lance Taylor :
> roy rosen writes:
>
>> 2010/10/26 Ian Lance Taylor :
>>> roy rosen writes:
>>>
I am trying to demonstrate my port capabilities.
I am writing an application which needs to use instructions like max
a,b,c,d,e,f where a,b,c are inputs and d,e,f are outpu
roy rosen writes:
> 2010/10/26 Ian Lance Taylor :
>> roy rosen writes:
>>
>>> I am trying to demonstrate my port capabilities.
>>> I am writing an application which needs to use instructions like max
>>> a,b,c,d,e,f where a,b,c are inputs and d,e,f are outputs.
>>> Is that possible to write an i
work?
First a code with memory accesses would be generated and then
optimizations would optimize it to use registers directly?
Roy.
>> So, I thought of implementing that with inline assembly but here I
>> encounter a different problem: The compiler does not understand the
>> instruc
roy rosen writes:
> Is there any another way to give attributes to inline assembly insns?
Not that I know of. It would be a useful feature in some cases, though
difficult to document.
For specific cases a backend can normally do better by providing builtin
functions.
Ian
But this lets you just set default attributes.
I want to set real attributes so that the compiler would be able to
know which insn can be parallelized with another.
Is there a different way?
Are you saying that an inline assembly statement would stay as is, and
would not be touched by the compiler
Quoting roy rosen :
Is there any another way to give attributes to inline assembly insns?
See define_asm_attributes.
Is there any another way to give attributes to inline assembly insns?
2010/10/26 Ian Lance Taylor :
> roy rosen writes:
>
>> If I want the compiler to understand the inline assembly is it
>> possible to write define_insn which would match the pattern that GCC
>> creates
roy rosen writes:
> If I want the compiler to understand the inline assembly is it
> possible to write define_insn which would match the pattern that GCC
> creates for the inline assembly and then GCC would be able to 'know'
> some attributes about this insn and would be
If I want the compiler to understand the inline assembly is it
possible to write define_insn which would match the pattern that GCC
creates for the inline assembly and then GCC would be able to 'know'
some attributes about this insn and would be able to parallelize it?
2010/10/26 roy r
verything out of memory I added
> additional intrinsics to retrieve elements of the struct. It's awkward
> to use but the resulting code is fine.
>
>> So, I thought of implementing that with inline assembly but here I
>> encounter a different problem: The compiler does not u
tional intrinsics to retrieve elements of the struct. It's awkward
to use but the resulting code is fine.
> So, I thought of implementing that with inline assembly but here I
> encounter a different problem: The compiler does not understand the
> instruction given in inline assembly
reference
which means that they would be in memory and not in a register as
meant by the instruction.
Is there any port with such an example?
So, I thought of implementing that with inline assembly but here I
encounter a different problem: The compiler does not understand the
instruction given in
Zoltán Kócsi writes:
> Is there a documentation of the various magic letters that you can
> apply to an operand in inline assembly?
Unfortunately, no.
> The
> only place I found some information was going through the
> gcc/config//.c file and trying to find the meaning of such
&
Is there a documentation of the various magic letters that you can
apply to an operand in inline assembly? What I mean is this:
asm volatile (
" some_insn %X[operand] \n"
: [operand] "=r" (expr)
);
What I look for is documentation of 'X'. In particular, w
Hello All the gurus,
I've been fiddling my luck with gcc 4.3.2 inline assembly on powerpc
There are a few queries
1. asm volatile or simply asm produce the same assembly code.
Tried with a few examples but didnt find any difference by adding
volatile with asm
2. Use of "memory"
On Mar 24, 2009, at 11:02 AM, Rodrigo Dominguez wrote:
When assembling this program, 'cc1' emits a 'shrl %ecx, %eax'
instruction.
The 'shr' instruction can only take an 8-bit register as the first
operand.
The emitted instruction should have been 'shrl %cl, %eax'.
Therefore, the
compilation
3 i386]$
H.J.
---
> Thank you,
>
> Rodrigo
>
>> -Original Message-
>> From: H.J. Lu [mailto:hjl.to...@gmail.com]
>> Sent: Tuesday, March 24, 2009 2:09 PM
>> To: Rodrigo Dominguez
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Inline Assembly Error
> "Rodrigo" == Rodrigo Dominguez writes:
Rodrigo> H.J, Thanks for replying but this doesn't answer my
Rodrigo> question. Shouldn't __asm__ generate the right code without
Rodrigo> using the %b1 trick? The reason I am asking is I have a 350
Rodrigo> line macro which I can't change.
GCC do
ssue? Something like an Intel/AMD/AT&T manual explaining this?
Thank you,
Rodrigo
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, March 24, 2009 2:09 PM
> To: Rodrigo Dominguez
> Cc: gcc@gcc.gnu.org
> Subject: Re: Inline Assembly
On Tue, Mar 24, 2009 at 11:02 AM, Rodrigo Dominguez wrote:
> Hi,
>
> While debugging a problem with Open64, I ran into a similar problem with
> GCC. I created the following unit test program:
>
> #include
>
> int main(void)
> {
> uint32_t a = 7;
> int8_t s = -1;
>
> __asm__ ("shr
Hi,
While debugging a problem with Open64, I ran into a similar problem with
GCC. I created the following unit test program:
#include
int main(void)
{
uint32_ta = 7;
int8_t s = -1;
__asm__ ("shrl %1, %0\n\t"
: "+r" (a)
: "c" (-s)
);
Till Straumann wrote:
> What is the proper way to tell gcc that a
> inline assembly statement either modifies
> a particular area of memory or needs it
> to be updated/in-sync because the assembly
> reads from it.
>
> E.g., assume I have a
>
> struct blah {
>i
> What is the proper way to tell gcc that a inline assembly statement either
> modifies
> a particular area of memory or needs it to be updated/in-sync because the
> assembly
> reads from it.
Maybe also related to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32642
i.e.
Hi.
What is the proper way to tell gcc that a
inline assembly statement either modifies
a particular area of memory or needs it
to be updated/in-sync because the assembly
reads from it.
E.g., assume I have a
struct blah {
int sum;
...
};
which is accessed by my assembly code.
int
Andreas Schwab wrote:
Till Straumann <[EMAIL PROTECTED]> writes:
asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p));
asm volatile ("lwz%U1%X1 %0, %1":"=r"(val):"m"(*reg_p));
Hmm - that is beyond me. What exactly do %U1 and %X1 mean?
I suspect that %U1 means that
Till Straumann <[EMAIL PROTECTED]> writes:
> asm volatile ("lwz %0, 16(%1)":"=r"(val):"b"(base),"m"(*reg_p));
asm volatile ("lwz%U1%X1 %0, %1":"=r"(val):"m"(*reg_p));
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germa
perand itself, unlike m68k, for example. The ia64 target has a
similar issue.
OK, so it's possible to get that right. Still - how many people
writing inline assembly do we think will do so?
This is back to something the S/390 maintainers were working on a few
months ago; in short
Andreas Schwab wrote:
Till Straumann <[EMAIL PROTECTED]> writes:
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
while (0)
Looking closer, your asm statement has a bug. The "m" constraint can
match memory addresses with s
nd itself, unlike m68k, for example. The ia64 target has a
>> similar issue.
>
> OK, so it's possible to get that right. Still - how many people
> writing inline assembly do we think will do so?
>
> This is back to something the S/390 maintainers were working on a few
&
imilar issue.
OK, so it's possible to get that right. Still - how many people
writing inline assembly do we think will do so?
This is back to something the S/390 maintainers were working on a few
months ago; in short the useful definition of "m" to GCC is not the
useful one for users,
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Mon, Mar 31, 2008 at 11:19:29AM +0200, Andreas Schwab wrote:
>> Till Straumann <[EMAIL PROTECTED]> writes:
>>
>> > /* Powerpc I/O barrier instruction */
>> > #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
>> > while (0)
d/store insns. If you don't
> use a load or store insn with the operand the you must use the "o"
> constraint to avoid the side effect.
Should asm "m" be required to carry out the side effect? It seems
like this would break every end-user use of inline assembly; you&
Till Straumann <[EMAIL PROTECTED]> writes:
> /* Powerpc I/O barrier instruction */
> #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m"(*pmem)); }
> while (0)
Looking closer, your asm statement has a bug. The "m" constraint can
match memory addresses with side effects (auto inc/dec),
Till Straumann <[EMAIL PROTECTED]> writes:
> In any case, bad code is also produced by gcc-4.3.0 if I omit the
> memory output operand and use an example that comes pretty
> close to what is in the gcc info page (example illustrating
> a memory input in the 'extended asm' section):
Would you mind
Daniel Jacobowitz wrote:
On Wed, Mar 26, 2008 at 09:25:05AM -0700, Till Straumann wrote:
Is my inline assembly wrong or is this a gcc bug ?
Your inline assembly seems wrong.
I'm not yet convinced about that...
/* Powerpc I/O barrier instruction */
#define EIEIO(pmem) do { asm vol
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> On Wed, Mar 26, 2008 at 09:25:05AM -0700, Till Straumann wrote:
>> Is my inline assembly wrong or is this a gcc bug ?
>
> Your inline assembly seems wrong.
I don't think so.
>> /* Powerpc I/O barrier instruction */
On Wed, Mar 26, 2008 at 09:25:05AM -0700, Till Straumann wrote:
> Is my inline assembly wrong or is this a gcc bug ?
Your inline assembly seems wrong.
> /* Powerpc I/O barrier instruction */
> #define EIEIO(pmem) do { asm volatile("eieio":"=m"(*pmem):"m&qu
result.
Is my inline assembly wrong or is this a gcc bug ?
(If the memory input operand to the inline assembly
statement is omitted then everything is OK).
Please CC-me on any replies; I'm not subscribed to the gcc list.
WKR
-- Till
###
Test case; C
polina <[EMAIL PROTECTED]> writes:
> I would like to use the asm feature of the gcc compiler. I am not sure what
> backends the asm supports. Would it support any backend for which it was
> compiled? The reason I asked is because I cross-compiled gcc for the PISA
> architecture and I haven't been
using asm to
do inline PISA assembly. I would appreciate any information. Thank you.
- Polina
--
View this message in context:
http://www.nabble.com/gcc-inline-assembly-tf4631623.html#a13225744
Sent from the gcc - Dev mailing list archive at Nabble.com.
On Jul 14, 2006, at 4:23 PM, [EMAIL PROTECTED] wrote:
Is it possible to use the register ebp in the input/output register
list
Wrong list. Also, for trivial questions like this, ask the compiler,
it will tell you.
hi,
Is it possible to use the register ebp in the input/output register list in
gcc's inline assembly (for the x86 platform)? If so, how? If not, why not? I
would like to use ebp just like the other general purpose registers, e.g.
triggering a software interrupt 0x80 with value i
On Apr 6, 2006, at 11:52 PM, Ching-Hua Chang wrote:
Is there a flag in gcc that indicate that we are in the inline
assembly ?
inside_cw_asm_block, but only the APPLE branch has a notion of being
`inside'.
I suspect you'll need to use a paragraph to ask your question for us
to
"Ching-Hua Chang" <[EMAIL PROTECTED]> writes:
> If it is possible to restrict the addressing mode
> of inline assembly?
Use an appropriate constraint.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nür
Hello ,
If it is possible to restrict the addressing mode
of inline assembly?
For example,in normal mode that we accept the
addressing mode BASE+OFFSET, but do not like
it in inline assembly.
Is there any one can give me a hand?
thanks a lot!
Aladdin
Hi,
Is there a flag in gcc that indicate that we are in the inline assembly ?
thanks,
Aladdin
Thanks for your help: using constraint "b" instead of "r" solved my problem.
-- Stefan
> Try using 'b' for the constraint - that selects for an "address base
> register", as opposed to 'r' that is any of the general registers
(including
> R0)
>> I have some problems with using inline PowerP
On Jul 17, 2005, at 19:15, Stefan wrote:
I have some problems with using inline PowerPC assembly in GCC
(4.0.1). Consider the following code:
void save_fp_register(double* buffer)
{
asm("stfd F0, 0(%0)" : : "r" (buffer) );
}
Try using 'b' for the constraint - that selects fo
> Stefan writes:
Stefan> I have some problems with using inline PowerPC assembly in GCC (4.0.1).
Stefan> Consider the following code:
Stefan> void save_fp_register(double* buffer)
Stefan> {
Stefan> asm("stfd F0, 0(%0)" : : "r" (buffer) );
Stefan> }
Use constraint "b".
David
I have some problems with using inline PowerPC assembly in GCC (4.0.1).
Consider the following code:
void save_fp_register(double* buffer)
{
asm("stfd F0, 0(%0)" : : "r" (buffer) );
}
When compiled with -Os the generated code becomes
save_fp_register:
stfd F0, 0(3)
2.15 but to some CVS snapshot (I suppose).
>
Correct. CVS as of the day it was submitted.
> My question on the usage of inline assembly regards omitting writing long jump
> tables (e.g. with nested switches). This is not usually necessary but it is
> when dealing with dynamic code ge
gcc-patch ml circa June 2002. It works, at least
for the things I have used it. Actually the patch doesn't correspond exactly to
either versions 2.13,2.14 or 2.15 but to some CVS snapshot (I suppose).
My question on the usage of inline assembly regards omitting writing long jump
tables (e.g. wi
On Tue, 2005-04-05 at 22:25 +0100, Richard Sandiford wrote:
> [EMAIL PROTECTED] writes:
> > asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
>
> In addition to Daniel's reply: you wouldn't want to use "r" here.
> That's for general registers only.
>
> The MIPS port does in theory support
[EMAIL PROTECTED] writes:
> asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
In addition to Daniel's reply: you wouldn't want to use "r" here.
That's for general registers only.
The MIPS port does in theory support coprocessors, but the functionality
isn't tested much (if at all). The c
Thanks Daniel!
actually my 2 messages were send back-to-back. I have just read both your
responses and I can see that i could use stringify approach to force the
assembly output of GCC to what I want.
Nikolaos Kavvadias
On Tue, Apr 05, 2005 at 07:27:00AM +0300, [EMAIL PROTECTED] wrote:
> I was wondering...
>
> why not support asm templates THAT ARE NOT string constants??? And I
> mean for static compilation cases only.
>
> For example:
>
> asm(instrx $%d, $%d\n",src1,src2 : "=r" (var1) : "r" (var2));
>
> I ass
microarchitecture is stable
> (works at register-transfer level, not subject to change). Plus, I
> would be happy NOT TO CHANGE my ISA add-on.
>
> My problem is that I would like to access specific indices in the data
> register file of COP2, i.e. registers c2r0 to c2r31. This should b
I was wondering...
why not support asm templates THAT ARE NOT string constants??? And I
mean for static compilation cases only.
For example:
asm(instrx $%d, $%d\n",src1,src2 : "=r" (var1) : "r" (var2));
I assume printf-like formating.
Or else you may need either write a double-nested switch (a
ld be happy NOT TO CHANGE my ISA add-on.
My problem is that I would like to access specific indices in the data
register file of COP2, i.e. registers c2r0 to c2r31. This should be
done in inline assembly or else I'll have to put down probably 2k-3k
C-lines in assembly :-)
Is it possible to
88 matches
Mail list logo
