bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/15348] GCC inline assembler for ARM thumb16 mnemonic lsls not r


From: eleventen at gmail dot com
Subject: [Bug gas/15348] GCC inline assembler for ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0
Date: Tue, 12 Aug 2014 17:33:19 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=15348

--- Comment #3 from eleventen at gmail dot com ---
(In reply to eleventen from comment #2)
> (In reply to DeepaB from comment #1)
> > "lsls" is equivalent UAL syntax for "lsl" thumb instruction."lsls"
> > instruction works if directive ".syntax unified" is specified.
> 
> Indeed, the fragment below compiles and assembles properly on the Cortex-M0.
> 
> void test () {
>   __asm volatile (".syntax unified\n\t" "lsls r0, #1\n\t" ".syntax divided");
> }

It looks like I wrote too soon.  The goal is to write one version of the C++
code that compiles on both M0 and M3/M4.  It looks like the compiler treats the
two architectures differently.

The top of the M0 .s output from compiling the code is 

    .cpu cortex-m0
    .fpu softvfp
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 1
    .eabi_attribute 30, 4
    .eabi_attribute 34, 0
    .eabi_attribute 18, 4
    .code    16
    .file    "test.cc"
    .text

But, the same code compiled for M4 already includes the .syntax directive.

    .syntax unified
    .cpu cortex-m4
    .eabi_attribute 27, 3
    .eabi_attribute 28, 1
    .fpu fpv4-sp-d16
    .eabi_attribute 20, 1
    .eabi_attribute 21, 1
    .eabi_attribute 23, 3
    .eabi_attribute 24, 1
    .eabi_attribute 25, 1
    .eabi_attribute 26, 1
    .eabi_attribute 30, 4
    .eabi_attribute 34, 0
    .eabi_attribute 18, 4
    .thumb
    .file    "test.cc"
    .text

The sample I wrote works fine on M0 because it returns the syntax to divided
after the LSLS opcode.  On M4, it doesn't work because the syntax must remain
unified.

As this stands there isn't a way for the C++ source code to declare a single
representation of the LSLS/LSL opcode that compiles and assembles for both
targets.  Sounds to me like an issue with the compiler.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]