Address for Memory#, good or bad ?

Codemonger · Post by **Codemonger** » Fri Dec 12, 2003 6:42 am

Hi everybody

Just wandering if anyone can forsee a huge problem with doing the following, or any future bugs that would crop up..

Create a linked list of memory addresses something like

Code: Select all

NewList MemoryAddresses.l()

then I would add the elements like so ...

Code: Select all

AddElement(MemoryAddresses())
MemoryAddresses() = @MemoryAddresses()

then I would allocate memory using

Code: Select all

AllocateMemory(MemoryAddresses() , XX-WhateverSize-XX, 0)

Just wandering if any problems would arise from using the actual address of the element to be used as the Memory# ... I would like to do this to kill two birds with one stone.

The reasone I would like to do this is to have a self incrementer for the memory commands without having to increment a value myself ... the address of the new element in the list will do it. Obviously when the element is destroyed I will deallocate the memory.

Froggerprogger · Post by **Froggerprogger** » Fri Dec 12, 2003 10:39 am

AllocateMemory() requests an ID as parameter. This ID has nothing to to with the real position in the program's memory, even if it is numerically the same as a memoryposition/pointer.
So there's absolutely no problem to do it this way.

AllocateMemory returns a pointer that points to free-to-use memory of the specified size.

freedimension · Post by **freedimension** » Fri Dec 12, 2003 11:55 am

I believe the following to be true, though I don't know for sure. Perhaps Fred can enlighten us.

The Memory Banks physical addresses are stored in an array where the index of the array represents the Memory Bank Number (#memory).
The way you determine the numbers requires an oversized lookup-table with millions of unused index positions.

Froggerprogger · Post by **Froggerprogger** » Fri Dec 12, 2003 12:42 pm

Huh! That would be really

Thanks for pointing this out!

Who can answer this ? Fred ?

Danilo · Post by **Danilo** » Fri Dec 12, 2003 1:18 pm

I dont understand why

Code: Select all

AllocateMemory(MemNumber, Size, 0): MemNumber + 1

isnt good enough.

The above stuff with a linked list ist just weird.

Here the memory-functions from C which dont use numbers
like the PB-Commands.... but WinAPI only:

Code: Select all

#HEAP_ZERO_MEMORY = $00000008

Procedure.l malloc(size)
  ProcedureReturn HeapAlloc_(GetProcessHeap_(),#HEAP_ZERO_MEMORY,size)
EndProcedure

Procedure.l free(mem)
  ProcedureReturn HeapFree_(GetProcessHeap_(),0,mem)
EndProcedure

Procedure.l realloc(mem,new_size)
  ProcedureReturn HeapReAlloc_(GetProcessHeap_(),#HEAP_ZERO_MEMORY,mem,new_size)
EndProcedure

Procedure.l msize(mem)
  ProcedureReturn HeapSize_(GetProcessHeap_(),0,mem)
EndProcedure


mem = malloc(1000)
Debug "mem at  :"+StrU(mem,#LONG)
Debug "mem size:"+StrU(msize(mem),#LONG)
Debug "filling mem..."

*x.BYTE = mem
For a = 0 To 255
  *x\b = a
  *x+1
Next a

mem = realloc(mem,2000)
Debug "mem at  :"+StrU(mem,#LONG)
Debug "mem size:"+StrU(msize(mem),#LONG)

Delay(2000)

; old content is still there after re-allocation !!

*x = mem
For a = 0 To 255
  Debug Chr(*x\b&$FF)
  *x+1
Next a

; mem is automatically freed on program exit,
; but you can also free it with free()
free(mem)

Codemonger · Post by **Codemonger** » Fri Dec 12, 2003 2:16 pm

AllocateMemory(MemNumber, Size, 0): MemNumber + 1

That is how I have it right now, and I forsee problems in the future, using a number that increments by one constantly.

I need to know that the memory# is going to be uniqie everytime so their is no overlap or room for error because their will be a lot of linked lists of memory buffers. It is for efficiency and would be used in the following fasion:

Code: Select all

MyPrimitive = ConstructCube(Width,Height,Depth,Flags)

the procedure would create a primitive object and add the object to a linked list of primitives, one global linked list for all primitives.

The procedure then returns a value, that value is a reference to the address of the current element created in the linked list.

In future code the programmer can use a function like so

Code: Select all

ResizePrimitve(MyPrimitve,Width,Height,Depth)

So internally in the ResizePrimitve i can easily set the proper element using the address passed by MyPrimitive.

Code: Select all

ChangeCurrentElement(Primitives(), PrimitiveAddress)

by not using the memnumber method I skip one line of code, which will be used more often than memnumber +1. I guess I am hoping this method is more effecient than using a static number. I just hope bugs don't crop up in the future.

Codemonger · Post by **Codemonger** » Fri Dec 12, 2003 3:03 pm

Hmm wait, I don't know if it would actually skip a step, but I now it definately wouldn't pass 0 for the first memory# and ... can't think of any other benifits right now, just need to know if a bug could arise, or if their is any limits to the memory# ?

blueznl · Post by **blueznl** » Fri Dec 12, 2003 3:05 pm

limit? i think there is... i couldn't use arbitrary numbers for openwindow() either... (<4096 or something iirc)

Codemonger · Post by **Codemonger** » Fri Dec 12, 2003 3:10 pm

Thanks blueznl, I hope Fred can confirm if their is a limit or not ...

Codemonger · Post by **Codemonger** » Sat Dec 13, 2003 1:38 am

Ok, I just tested the limits of memory#, and it is limited ... so using an address for the mem# is probably not a good idea. I tested with and without the debugger. It created some strange anomilies, and slowed down the higher the index number I used ... like using 25 million etc..

I will look into using WinAPI like Danilo posted.