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




Reply via email to