gnupic: Thread: Re:some problem in source code--gpmemory.c


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Re:some problem in source code--gpmemory.c
From: Joe Pfeiffer ####@####.####
Date: 11 Jul 2012 15:38:13 -0000
Message-Id: <20477.40415.93532.661322@pfeifferfamily.net>

After a brief look, it appears the address being passed isn't memory
allocated by malloc() or free() -- it isn't even an address in the
host machine's memory space.  It's an address in the PIC processor for
which code is being generated.

The assembler is maintaining a linked list of memory blocks
(MemBlocks), for which code has been generated for the PIC processor.
When you call b_memory_put(), it attempts to find a MemBlock
containing that address.  If it can't find one, it calls
i_memory_new() to create one; it calls malloc() to allocate a new
memory block as part of the call.

When you get inside i_memory_new(), you end up defining the starting
address of the MemBlock() on a 16-bit boundary (in PIC space).
After you get it back, you assign to the correct byte in the
MemBlock's buffer.

feqin fan writes:
>Hi,It's me Again.  (# ̄�� ̄#)
>
>../gputils-0.14.2/gputils-0.14.2/libgputils/gpmemory.c
>
>in the Line 132 the source code is :
>
>  int b_memory_get(MemBlock *m, unsigned int address, unsigned char *byte)
>  {
>
>    do {
>      assert(m->memory != NULL);
>
>      if( ((address >> I_MEM_BITS) & 0xFFFF) == m->base ) {
>        *byte = m->memory[address & I_MEM_MASK] & 0xFF;
>        return (m->memory[address & I_MEM_MASK] & BYTE_USED_MASK) != 0;
>      }
>
>      m = m->next;
>    } while(m);
>
>    return 0;
>  }
>
>I can see that the MemBlock->base must be the high 16 bit of the second
>parameter address(I called this ****conclusion A****).
>
>BUT,function b_memory_put (in Line 163) have source line (Line 187 and 188)
>>>   m = i_memory_new(i_memory, (MemBlock *) malloc(sizeof(MemBlock)),
>address);
>       m->memory[address & I_MEM_MASK] = value | BYTE_USED_MASK;
>
>but we can not make sure it accord with conclusion A, the address return by
>calloc and malloc is random..
>
>so who can tell me why??
>THX guys..
>
>---------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>live long and prosper..

-- 
Joe Pfeiffer                                   http://pfeifferfamily.net/
1440 Tierra del Sol Dr                         575.525.2764 (H)
Las Cruces, NM 88007                           575.496.3501 (C)
[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.