Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:58:20
|
Borja Ferrer wrote:
> WOW!!! very nice :)
>
> 1) Is the issue with int16_t related to what we discovered yesterday? So
> is sizeof(int) == sizeof(int16_t) true?
Yes its true. It is different issue. It just treats attributed int and
just-int as different types.
> 3) Commit this patch to SVN, and create a new directory for it, John any
> suggestions about the dir structure for this?
My suggestion is still to use GIT. From moment I started to work on
inlineasm I kept everything in GIT on github, syncing with your svn repo
from time to time.
> 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.
I wrote you few days ago (it is not for avr2, I found this fires for
avr5 as well):
>
> About compiling avrlibc:
>
> >> Also avr-clang emits wrong sequense for .S files. So I'm using
> CCAS=avr-gcc.
> What do you mean with this? What is wrong?
Directory:
bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/at90s1200
bash:$ avr-clang -DHAVE_CONFIG_H -I.
-I../../../../../avr-libc/avr/lib/avr2/at90s1200 -I../../../..
-I../../../../../avr-libc/common -I../../../../../avr-libc/include
-I../../../../include -I../../../../../avr-libc/common
-I../../../../../avr-libc/include -I../../../../include -x
assembler-with-cpp -mmcu=at90s1200 -DIOSYMFILE=\"iosym/at90s1200.S\"
-MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo -c -o gcrt1.o
../../../../../avr-libc/crt1/gcrt1.S
tons of errors.
I suppose thats because clang driver uses different tools for asm files.
For the -### command avr-clang shows the next:
"avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free"
"-main-file-name" "gcrt1.S" "-mrelocation-model" "static"
"-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases"
"-target-linker-version" "2.22.90.20120924" "-coverage-file"
"/tmp/gcrt1-fecbe5.s" "-resource-dir"
"/media/stepan/workproj/llvm.project/2-avr/builds/llvm.debug-avr-arm-x86_64.build/Debug+Asserts/bin/../lib/clang/3.4"
"-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT"
"gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" "IOSYMFILE=\"iosym/at90s1200.S\""
"-I" "." "-I" "../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I"
"../../../.." "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include" "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-fno-dwarf-directory-asm"
"-fdebug-compilation-dir"
"/media/stepan/workproj/llvm.project/2-avr/avr-libc/trunk/build.opt/avr/lib/avr2/at90s1200"
"-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign"
"-fobjc-runtime=gcc" "-fobjc-default-synthesize-properties"
"-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops"
"-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp"
"../../../../../avr-libc/crt1/gcrt1.S"
"/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I"
"../../../../../avr-libc/avr/lib/avr2/at90s1200" "-I" "../../../.." "-I"
"../../../../../avr-libc/common" "-I" "../../../../../avr-libc/include"
"-I" "../../../../include" "-I" "../../../../../avr-libc/common" "-I"
"../../../../../avr-libc/include" "-I" "../../../../include"
"-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.S\"" "-MT" "gcrt1.o"
"-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" "-x" "assembler"
"/tmp/gcrt1-fecbe5.s"
While avr-gcc uses next sequence:
/usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I
../../../../../avr-libc/avr/lib/avr2/at90s1200 -I ../../../.. -I
../../../../../avr-libc/common -I ../../../../../avr-libc/include -I
../../../../include -I ../../../../../avr-libc/common -I
../../../../../avr-libc/include -I ../../../../include -MD gcrt1.d -MF
.deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D
"IOSYMFILE=\"iosym/at90s1200.S\"" ../../../../../avr-libc/crt1/gcrt1.S
"-mmcu=at90s1200" -fno-directives-only -o /tmp/ccK7jMC3.s
'-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"' '-MT' 'gcrt1.o'
'-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o'
/usr/lib/gcc/avr/4.7.0/../../../avr/bin/as "-mmcu=at90s1200"
-mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s
> 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... <mailto: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...>
> <mailto: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...>>
> <mailto: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...>>> <mailto: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...>>__>__>
>
> <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...
> <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...>>>>
>
> <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...
> <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...>>__>__>
>
> <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...
> <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...>>__>__>
>
> <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...
> <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
> <mailto:avr...@li...>
> https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel
> <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>
>
>
>
|
