hm... something is really wiered happens... could please you send me sources? ~d
On Saturday 07 December 2002 00:52, Mark Stokes wrote: > 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: mspgcc-users-ad...@lists.sourceforge.net > [mailto:mspgcc-users-ad...@lists.sourceforge.net] On Behalf Of Dmitry > Sent: Friday, December 06, 2002 2:02 PM > To: mspgcc-users@lists.sourceforge.net > 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: mspgcc-users-ad...@lists.sourceforge.net > > [mailto:mspgcc-users-ad...@lists.sourceforge.net] On Behalf Of Chris > > Liechti > > Sent: Thursday, December 05, 2002 2:51 PM > > To: mspgcc-users@lists.sourceforge.net > > Subject: Re: [Mspgcc-users] Inline ASM question (Possible compiler bug) > > > > Am 05.12.2002 18:19:11, schrieb "Mark Stokes" <m.sto...@ieee.org>: > > >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 > > Mspgcc-users@lists.sourceforge.net > > 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 > > Mspgcc-users@lists.sourceforge.net > > 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 > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users -- ********************************************************************* ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia (il),-'' (li),' ((!.-' +7 (812) 314-8860, 5585314 *********************************************************************
