Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Borja F. <bor...@gm...> - 2013-07-29 18:52:03
|
WOW!!! very nice :)
1) Is the issue with int16_t related to what we discovered yesterday? So is
sizeof(int) == sizeof(int16_t) true?
2) What sort of errors do you get without setting the CCAS line? Again,
avr-clang should call avr-as if it's in the $PATH.
3) Commit this patch to SVN, and create a new directory for it, John any
suggestions about the dir structure for this?
I will fix those two issues later, we still need to fix or report the mode
thing though.
2013/7/29 Stepan Dyatkovskiy <stp...@na...>
> Stepan Dyatkovskiy wrote:
>
>> Gotcha!!!
>>
> I mean, I have compiled it successfully :-)
>
>
>> In output I send you patch for avr-libc.
>> Remained issues:
>> -- PR16712,
>> -- Bug with 'mode' attr in SemaDeclAttr, handleModeAttr function
>> -- AVRTargetInfo, size of double
>> -- AVRAsmPrinter, emit asm header.
>> -- By some strange reason avr-clang treats differently with 'int' and
>> int16_t (that is the same int, but with attribute added), so the next
>> one causes error:
>> int foo(); // header
>> int16_t foo() { return 0; } // .c file.
>>
>> -- But currently (you will see in patch) I fixed their stdint.h.
>> -- I'm still using CCAS=avr-gcc
>>
>> Though I think we already have solution for TargetInfo and AsmPrinter.
>>
>> Configure command:
>> $AVR_LIBC_SRC/configure CC=$AVR_CLANG_BIN/avr-clang --build= --host=avr
>> CCAS=avr-gcc
>>
>> -Stepan.
>>
>>
>> Borja Ferrer wrote:
>>
>>> Yes, that's the way of doing it, thanks for the code, I will add it
>>> later.
>>>
>>> So how many files have you successfully compiled so far?
>>>
>>>
>>> 2013/7/29 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>>
>>>
>>> Just in case, I have already added temporary it in my sources. To do
>>> that you should implement AVRAsmPrinter::__**EmitStartOfAsmFile
>>> method
>>> (that is virtual for AsmPrinter). Currently it looks like:
>>>
>>> void AVRAsmPrinter::__**EmitStartOfAsmFile(Module &M) {
>>> // FIXME: Perhaps do it somehow with OutStreamer.EmitAssignment
>>> OutStreamer.EmitRawText(__**StringRef(
>>> "__SP_H__ = 0x3e\n\t"
>>> "__SP_L__ = 0x3d\n\t"
>>> "__SREG__ = 0x3f\n\t"
>>> "__tmp_reg__ = 0\n\t"
>>> "__zero_reg__ = 1\n\t"
>>> ));
>>> }
>>>
>>>
>>> Borja Ferrer wrote:
>>>
>>> Ok yes I will add this tonight.
>>>
>>> El lunes, 29 de julio de 2013, Stepan Dyatkovskiy escribió:
>>>
>>> Yes. I mean just header for .s file, so it should be
>>> equal to
>>> avr-gcc. For set_system_time.c gcc produces next header:
>>>
>>> .file "set_system_time.c"
>>> __SP_H__ = 0x3e
>>> __SP_L__ = 0x3d
>>> __SREG__ = 0x3f
>>> __tmp_reg__ = 0
>>> __zero_reg__ = 1
>>> ...
>>>
>>> Just compare our output and one generated by gcc (in
>>> attachment).
>>>
>>>
>>>
>>> Borja Ferrer wrote:
>>>
>>> You mean in the header (top) of the .S file instead
>>> of the
>>> footer no?
>>>
>>>
>>> 2013/7/29 Stepan Dyatkovskiy <stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>>
>>> Currently I have found that set_system_time.c
>>> hardcodes
>>> __SREG__ and
>>> __tmp_reg__ names in inlineasm. GCC just puts the
>>> footer
>>> for all .s
>>> files:
>>> __SP_H__ = 0x3e
>>> __SP_L__ = 0x3d
>>> __SREG__ = 0x3f
>>> __tmp_reg__ = 0
>>> __zero_reg__ = 1
>>>
>>> Can we do the same?
>>>
>>> -Stepan.
>>>
>>> Borja Ferrer wrote:
>>>
>>> Hello Stepan,
>>>
>>> 1) Yes, I'm aware of our double width
>>> definition in
>>> clang. I
>>> have to do
>>> some tests before changing it in clang and
>>> other places
>>> back to
>>> 32bits,
>>> so in the meantime it's ok to leave that
>>> change locally
>>> for you.
>>>
>>> 2) If I understand that code correctly they
>>> are setting
>>> SI to an
>>> integer
>>> type which is 16bits for our target. If
>>> that's the
>>> case, they
>>> have to
>>> take care of ints being smaller than 32
>>> bits. They
>>> check in the
>>> 64bit
>>> case for the long type width and do it right
>>> there. So
>>> I would
>>> say fill
>>> in a bug report or send them a patch if you
>>> have the fix.
>>>
>>> Btw, if you want, create a branch in svn and
>>> add there
>>> all the
>>> avrlibc
>>> patches and stuff instead of getting them lost
>>> here in the
>>> mailing list.
>>>
>>>
>>>
>>> 2013/7/29 Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>>>
>>>
>>>
>>> Currently I'm considering it as clang
>>> bug. In
>>> handleModeAttr they
>>> handle 'SI' as 32 bit value (that's ok
>>> for us, but
>>> instead
>>> it should
>>> be 4*QI), and what is really wrong for
>>> AVR is how
>>> 32 value
>>> type is
>>> handled here:
>>>
>>> case 32:
>>> if (!IntegerMode)
>>> NewTy = S.Context.FloatTy;
>>> else if
>>> (OldTy->isSignedIntegerType())
>>> NewTy = S.Context.IntTy;
>>> else
>>> NewTy = S.Context.UnsignedIntTy;
>>>
>>> -Stepan.
>>>
>>> Stepan Dyatkovskiy wrote:
>>>
>>> Hi Borja,
>>>
>>> In clang/lib/Basic/Targets.cpp,
>>>
>>> AVRTargetInfo::AVRTargetInfo()**________, I have
>>>
>>>
>>> changed DoubleWidth to 32 bit value.
>>> Is it
>>> legal? I
>>> mean why it
>>> was 64
>>> bits, doesn't it has some pitfalls?
>>> Anyway I
>>> allowed me to
>>> compile that
>>> large source.
>>>
>>> > > typedef unsigned int
>>> uint32_t
>>> __attribute__
>>> ((__mode__
>>> > (__SI__)));
>>>
>>> I have found the next info about it
>>>
>>>
>>> (http://www.delorie.com/gnu/__**______docs/gcc/gcc_80.html<http://www.delorie.com/gnu/________docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**____docs/gcc/gcc_80.html<http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>
>>> >
>>> <http://www.delorie.com/gnu/__**
>>> ____docs/gcc/gcc_80.html<http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> >>
>>>
>>> <http://www.delorie.com/gnu/__**____docs/gcc/gcc_80.html<http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> >
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**docs/gcc/gcc_80.html<http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>
>>> >>>
>>>
>>>
>>>
>>> <http://www.delorie.com/gnu/__**____docs/gcc/gcc_80.html<http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> >
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**docs/gcc/gcc_80.html<http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>
>>> >>
>>>
>>> <http://www.delorie.com/gnu/__**__docs/gcc/gcc_80.html<http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/__**docs/gcc/gcc_80.html<http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>
>>> >
>>> <http://www.delorie.com/gnu/__**docs/gcc/gcc_80.html<http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>
>>> <http://www.delorie.com/gnu/**docs/gcc/gcc_80.html<http://www.delorie.com/gnu/docs/gcc/gcc_80.html>
>>> >>>>):
>>>
>>>
>>> QI -- An integer that is as wide as
>>> the smallest
>>> addressable unit,
>>> usually 8 bits.
>>> HI -- An integer, twice as wide as a
>>> QI mode
>>> integer,
>>> usually 16
>>> bits.
>>> SI -- An integer, four times as wide
>>> as a QI
>>> mode integer,
>>> usually 32 bits.
>>> DI -- An integer, eight times as wide
>>> as a QI
>>> mode integer,
>>> usually 64
>>> bits.
>>> SF -- A floating point value, as wide
>>> as a SI
>>> mode integer,
>>> usually 32
>>> bits.
>>> DF -- A floating point value, as wide
>>> as a DI
>>> mode integer,
>>> usually 64 bits.
>>>
>>> It is implemented in
>>> clang/lib/Sema/SemaDeclAttr.__**______cpp, in
>>>
>>>
>>> handleModeAttr
>>> static function.
>>>
>>> Perhaps we just have to sort it out in
>>> AVRTargetInfo...
>>>
>>> -Stepan.
>>>
>>> Borja Ferrer wrote:
>>>
>>> Found it, the isfinite() function
>>> takes in a
>>> double, and
>>> since our
>>> backend treats them as 64bit
>>> types this
>>> fails in
>>> inline asm.
>>> Removing
>>> the function implementation and
>>> just
>>> leaving it as
>>> an extern
>>> compiles
>>> successfully.
>>>
>>>
>>> 2013/7/28 Borja Ferrer
>>> <bor...@gm... <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>__>
>>>
>>> I've tried different
>>> optimization
>>> levels and
>>> they all
>>> fail for me.
>>> The interesting thing is
>>> that i've
>>> isolated
>>> the strtod
>>> function in a
>>> different file and it
>>> compiles fine,
>>> so there's
>>> something in the
>>> huge file that causes this.
>>>
>>>
>>> 2013/7/28 Stepan Dyatkovskiy
>>> <stp...@na... <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na... <mailto:stp...@na...>>>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>> <mailto:stp...@na...
>>> <mailto:stp...@na...>
>>> <mailto:stp...@na...
>>> <mailto:stp...@na...>>>>>
>>>
>>>
>>>
>>>
>>> > Ok this was a bit
>>> insane to
>>> reduce but
>>> I've
>>> found the
>>> offending lines.
>>> >
>>> > The problem is how
>>> uint32_t and
>>> uint16_t are
>>> defined:
>>> > typedef unsigned int
>>> uint16_t
>>> __attribute__
>>> ((__mode__
>>> (__HI__)));
>>> >
>>> > typedef unsigned int
>>> uint32_t
>>> __attribute__
>>> ((__mode__
>>> (__SI__)));
>>> >
>>> > I have no idea
>>> what this
>>> syntax is,
>>> but if you
>>> refedefine
>>> those types to unsigned
>>> int /
>>> long the
>>> problem
>>> goes away.
>>>
>>> Wow great. Never
>>> expected that wrong
>>> definition.
>>>
>>> >
>>> > Now im getting an
>>> error in
>>> llc: error:
>>> couldn't
>>> allocate
>>> input reg for
>>> constraint 'r'
>>> >
>>>
>>> Hm.. May be try with O2
>>> instead
>>> of Os?
>>>
>>> > 2013/7/28 Borja
>>> Ferrer
>>> <bor...@gm...
>>> <mailto:bor...@gm...> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>
>>>
>>> <mailto:bor...@gm... <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>__>
>>> >
>>> >> I've compiled the
>>> file you
>>> attached,
>>> ignoring
>>> all warnings i
>>> get from clang about
>>> the unknown
>>> attributes like
>>> progmem, i'm
>>> getting the assertion
>>> "multibyte
>>> index is
>>> out of
>>> range."
>>> >>
>>> >> 2013/7/28 Borja
>>> Ferrer
>>> <bor...@gm...
>>> <mailto:bor...@gm...> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>
>>>
>>> <mailto:bor...@gm... <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>
>>> <mailto:bor...@gm...
>>> <mailto:bor...@gm...>**>__>__>__>
>>> >>
>>> >>> Hello Stepan,
>>> >>>
>>> >>> 1) It seems clang
>>> mangles
>>> assembly
>>> functions
>>> names by
>>> prefixing a \01
>>> character. I haven't
>>> found yet the
>>> code that
>>> does this depending
>>> on the
>>> target used.
>>> >>>
>>> >>> 2) About the code
>>> above, I'm
>>> assuming you got
>>> that inline
>>> asm code from the
>>> __LPM_dword_classic__
>>> macro.
>>> This is what I'm
>>> getting for the
>>> following C code:
>>> >>> typedef unsigned
>>> int uint16_t;
>>> >>> typedef unsigned
>>> long uint32_t;
>>> >>>
>>> >>> #define
>>> __LPM_dword_classic__(addr) \
>>> >>> (__extension__({ \
>>> >>> uint16_t __addr16 =
>>> (uint16_t)(addr); \
>>> >>> uint32_t
>>> __result; \
>>> >>> __asm__
>>> __volatile__ \
>>> >>>
>>> >>> ( \
>>> >>> "lpm" "\n\t" \
>>> >>> "mov %A0, r0"
>>> "\n\t" \
>>> >>> "adiw r30, 1"
>>> "\n\t" \
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.**net/gampad/clk?id=49501711&iu=**
>> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk>
>>
>>
>>
>>
>> ______________________________**_________________
>> avr-llvm-devel mailing list
>> avr-llvm-devel@lists.**sourceforge.net<avr...@li...>
>> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>
>>
>>
>
|
