Times:
Using C : 0x102 bytes (256 dec)
Some execution times:
Value Time (uS)
12345678 456.0
034 248.0
12300678 456.0
0 204.0
Using naked Asm : 0x6A bytes (106 dec)
Value Digit Time (uS)
12345678 8 256.0
034 3 136.0
12300678 8 256.0
0 8 252.0
Pretty impressive I must say. Probably if anything I have proven to myself
that in the very least, the C is "good enough" and if further "tweaking" of
the code is necessary to save battery power, I can do that at a later time
(and just replace the C w/ the asm). 200uS ain't "chump change", but I
think for now it is fast enough.
Thanks for the help all.
-Mark
PS. I didn't say that reading the docs was not useful, what I did say was
that I didn't find the #define problem I was having anywhere in the Docs. I
had printed and read multiple times the pages that Chris suggested long
before I wrote the original inquiry.
The 95 bytes thing was an estimation of the number of bytes gcc was
generating for this particular function, not for the entire program. As you
can see, it was far more than 95.
I do not know where "doc.txt" is located. It didn't install on my win32
installation. I did read over the docs you have online and learned quite a
bit from them (ie. Register usage/allocation for functions which I am
using).
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dmitry
Sent: Friday, December 06, 2002 2:02 PM
To: [email protected]
Subject: Re: [Mspgcc-users] Inline ASM question (Possible compiler bug)
> the Registers directly. As for the loading of the variables directly
> using the parameter passing into assembly, I'll probably have to do that
> for this particular variable.
This is not really _optimal_ if you do not know where the particular
variable
located. For example, if you think, that the_variable should be located in a
register, but this is really isn't, gcc will issue somem more insn, which
will:
- rearrange registers,
- load your var to reg,
- output your asm code,
- store var in the particular place.
So, you have to make some compiling iterrations before you'll find a
suitable
place for the var and a good way to pass this to the asm operand.
More - large chunks of assembly code really breaks gcc's codeflow. So, to
achieve a maximum gcc performance it is good to output 'assign' only via
assembler calls (I mean no inputs - just output params only)
I do not want to say, that inline assembly is bad thing - I'm using this a
lot
(I just can roughly predict gcc output... sometimes... sometimes not...)
But all above should be taken into account.
Another way (and I'm using this a lot too) - just write entirly function in
assembler (mart the function naked and so on...) But....
> I did not appreciate the mention for me to read the docs, since I found
> nowhere in the docs (the gcc .ps file), where it states that I can't
> reference a #define directive in my inline asm.
> I am able to do this operation in C. However, in my particulate case,
> The asm I wrote is approx 50 bytes, and the asm that mspgcc wrote is
> about 95 bytes. I haven't timed the asm yet, but I suspect it will be
> a bit faster, and as we all know... Time is electrons (or battery life).
Yes, just try to time it. This is a common mistake that more code is less
performance. For large code (actually always) gcc tries to find a 'lowest
cost' for operations. Really, some function might look bigger cause there
are
some stack <-> register reloads. However if some var being used a lot this
is better to keep it in register and reload less, than another, which can be
kept on stack. So, in general, gcc does a good _TIME_ optimization job. Time
is money :) Batteries cost money :)
So, it might be you'll find a better approach to write efficiently some
_really_ small piece of code in assembly, but I doubt you'll calculate a
cost
of loarge code better than machine.
And 95 bytes of gcc output is _impossible_ :)
>
> Anyway, RTFM doesn't help.
It really does. The thing you've asked I explained a lot here in the list
and
as info files explains this as well. In libc/doc file doc.txt explains full
ABI, registers usage, inline asm., etc...
~d
> -Mark
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Chris
> Liechti
> Sent: Thursday, December 05, 2002 2:51 PM
> To: [email protected]
> Subject: Re: [Mspgcc-users] Inline ASM question (Possible compiler bug)
>
> Am 05.12.2002 18:19:11, schrieb "Mark Stokes" <[email protected]>:
> >Of course ultimately, the more logical solution would be to use a
> >#define for this. Or just use the predefined LCDMEM (in lcd.h). And I
> >would do this, but apparently, ASM statements can't see #define'd
> >variables. Is this a bug?
>
> no. it's how it is. the asm part is just written to the intermediate
> assembler output
> from gcc, the preprocessor is not started twice (or again for the
> intermediate asm)
>
> your problem can be solved with parameters to the asm statement. (if you
> realy
> want that asm. i think you could do that also in C)
>
> asm("":outputs:inputs:clobbers)
> so you can pass in and out variables or constants. the clobbers
> statement
> is a list of registers you modify (in your case R11). gcc saves and
> restores
> that registers if needed.
>
> example of an out param:
> __asm__ __volatile__ ("mov.w R1,%0" : "=r"
> (currentTask->stack));
> example of an inparam:
> __asm__ __volatile__ ("mov.w %0,R1" : : "m"
> (currentTask->stack));
>
> and maybe have a look at this doc:
> http://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_5.html#SEC102
>
> (i think you shoud not use R15, R14 in the asm direclty, but pass then
> as in params:
> __asm__ __volatile__ ("xxx" : : "r"(value), "r"(digit));
> )
>
> and maybe string concatenation works? i haven't tried this, but the
> preprocessor
> usualy concatenates strings that follow each other, so:
>
> "\tBIS.B " str(LCDASCII) "+0x10(R11), ..."
>
> should produce one string, assuming :
> #define str_x(x) #x
> #define str(x) str_x(x)
> or something like that (keyword "stringify")
>
> chris
>
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
