Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Borja F. <bor...@gm...> - 2013-07-29 16:48:12
|
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> >> >>): >> >> >> 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" \ >> > > |
