ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá












     áòèé÷ :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[filmscanners] RE: Digital Darkroom Computer Builders?



Andras,

> Change
> the kernel, and applications have access to more memory.

Up to the limit of the pointer and/or size variables used.  If your code
only uses 32 bit pointers for memory reference, then you are limited to a
starting address within that 32 range, and if you use that pointer for
addressing the range, you are limited to the upper limit of 2**32.  Also, if
your "size" variable is 32 bits, then you only have access to 2**32 "units"
(typically bytes) of memory.

If you (not you specifically) understand how virtual memory works, and how
memory is allocated in a lot of OSs, you'll know it's allocated in rather
small chunks...and what the kernel process gets is a linked list that
contains pointers to the different segments of the overall space you
requested.  Say, you request 64K, you get 16 4k chunks...  The address
translation done by the OS makes that LOOK like it's contiguous to your
application, but in reality it isn't.  There is inherent address translation
done in the CPU hardware.

Austin

----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 
body



 




Copyright © Lexa Software, 1996-2009.