Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Borja F. <bor...@gm...> - 2013-07-29 17:04:10
|
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...>
> 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...>>
>>
>> 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...>>>
>>
>>
>> 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...>**>__>__>
>>
>> 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...>>>>
>>
>>
>>
>>
>> > 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...>**>__>__>
>> >
>> >> 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...>**>__>__>
>> >>
>> >>> 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" \
>>
>>
>
|
