Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:32:55
|
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>>>>):
>>
>>
>> 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
>
>
>
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
|
