Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:56:34
|
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>>>):
>
>
> 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" \
>
|
