Compiler does it in two steps as it were char values
So it writes low byte and afterwars high byte with zeros.
Maybe there is a bug inside a chip, what I understand, but if it's compiler
idea I don't
robert
On Sunday 20 of June 2004 21:34, Chris Liechti wrote:
> Robert Seczkowski wrote:
> > I think, that the guy who writes th code should be prior to compiler
> > So if I say
> > (int)x * (int)144
>
> if you want unsigned ints write it as (unsigned int)x * (unsigned int)144
> dont complain when the C compiler does what whats its' sposed to do ;-)
>
> > I think it should be simple to the compiler to
> > understand what I want.
>
> you write: a signed 16 bit multiplication with a 16 bit result.
>
> > But mspgcc wants to be smarter, and thats bad.
> >
> > I rewritten code in asm, it works with all int's and it saves 50 bytes of
> > flash.
> > robert
> >
> > On Friday 28 of May 2004 08:34, Dima wrote:
> >>>1. Can anyone see reason why is push r2, and pop SR. Is it for fun?
> >>
> >>These are disassembly tricks. Compile your source with -S flag then see
> >>_pure_ assembly.
> >>
> >>>2. has anyone found in early math lessons, that 144 = -112 !!!?
> >>
> >>You already answered your question below.
> >>
> >>>I fully understand, that 112+144 = 256. I also understand, that 2+2=4
> >>
> >>This might be an answer.
> >>
> >>>But these are not what states in C.
> >>
> >>they are.
> >>
> >>>Funny is that if constant is below 126 everything is OK.
> >>>casting to int doesn't help
> >>>I am used to write HW mul myself but after 1 year and many updates I
> >>>thought somebody has fixed it up.
> >>
> >>t= usart0_rx_buffer[usart0_rx_extract_idx]*144;
> >> mov #642, r13 ;#0x0282
> >> mov &0x026c,r15 ;src addr 0x026c
> >> add r13, r15 ;
> >> push r2 ;
> >> dint
> >> nop
> >> mov.b @r15, &0x0130 ;
> >> mov.b #0, &0x0131 ;subst r3 with As==00
> >>mov #-112, &0x0138 ;#0xff90
> >>mov.b #0, &0x0139 ;subst r3 with As==00
> >>
> >>These two load second operand with int 144 (tricky, isn't it? :)
> >>
> >>
> >> mov &0x013a,r10 ;src addr 0x013a
> >> pop SR
> >>this is the same as pop r2 (disassembly tricks only!)
> >>
> >>>I have also suggestion to free(void* ptr) in malloc( which I am using
> >>
> >>for
> >>
> >>>ages. It helps me to free not only memory allocated via malloc, but
> >>
> >>also
> >>
> >>>pointers to memory in eeprom- which I directly use via pointer. I call
> >>>
> >>>free() without worring if deallocation is possible. I also must
> >>
> >>mention,
> >>
> >>>that first int after __noinit_end is used to store value of memory
> >>
> >>size
> >>
> >>>allocated with malloc.(*t)
> >>>So if p is not withing malloc range no action is taken.
> >>
> >>That's correct.
> >>
> >>
> >>void myfree (void *p)
> >>{
> >> size_t *t = &__noinit_end;
> >> if(((int)p < ((int)t +*t)) && ((int)p > (int)t)){
> >> p--;
> >> *t -= XSIZE(((size_t*)p));
> >> MARK_FREE (((size_t*)p));
> >> }
> >>}
> >>
> >>
> >>~d
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
Regards
Robert Seczkowski
robert.seczkow...@sz.onet.pl
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\
