Re: Integer Division on 32 Bit Machines
Hi Dave, On Thu, Sep 09, 2010 at 06:16:07PM -0700, Dave Hylands wrote: I've understood so far your explanations. But one thing I am missing: I claim that I do not do an 64-bit division, but an 32-bit division. Why? I have run make tags to create an architecture dependent tags file. When I go to s64 and jump to the definition I land in include/asm-generic/int-l64.h . There is the typedef: typedef signed long s64; I think you're looking in the wrong file. include/linux/types.h includes asm/types.h arch/x86/include/asm/types.h includes asm-generic/types.h include/asm-generic/types.h includes asm-generic/int-ll64.h include/asm-generic/int-ll64.h has the following typedef for s64: typedef signed long long s64; which is in fact a 64-bit type. You're right. I've misused ctags within vim - it was configured to jump to the first entry if there are several files found (for vim users: now I use g] instead of CTRL-] so that I get a list of all hits). So for example I get for g] on s64 the following list (showing only the first two hits): # pri verw. tag Datei 1 F ts64 include/asm-generic/int-l64.h typedef signed long s64; 2 F ts64 include/asm-generic/int-ll64.h typedef signed long long s64; ... Is there any way to know which one is the correct one, i.e. the one which is really used in my context? Am I correct that arch/x86/include/asm/types.h is for all 32-bit machines and arch/ia64/include/asm/types.h is for all 64-bit machines with an intel compatible architecture? Thanks again! Andreas -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Integer Division on 32 Bit Machines
Hi Dave, On Wed, Sep 08, 2010 at 11:14:30PM -0700, Dave Hylands wrote: Replying to the list this time... finally an answer to *my* problem, thanks :-D Another general rule, is that on 32-bit CPUs you can only do 32-bit arithmetic, with 64-bit addition, subtraction, and multiplications. 64-bit divides must be done using do_div or do_div64. I've understood so far your explanations. But one thing I am missing: I claim that I do not do an 64-bit division, but an 32-bit division. Why? I have run make tags to create an architecture dependent tags file. When I go to s64 and jump to the definition I land in include/asm-generic/int-l64.h . There is the typedef: typedef signed long s64; On my system, the size of long int is the same as int (I've wrote a simple C program to get this information). I.e. there should be no difference between an 'signed int division' and an 'signed long division'. What am I missing? Another question: I've encountered several #ifdef __ASSEMBLY__ and __KERNEL__ in the header files. What do these two preprocessor definitions stand for? Thanks in advance for your help! Andreas -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Integer Division on 32 Bit Machines
Hello,
I have encountered a problem on my 32 bit machine. Here some code
snippets:
typedef signed long s64;
asmlinkage long sys_optStopMeasure(int __user workamount) {
s64 currentPerformance, currentTimePerWork;
...
currentTimePerWork = currentPerformance / workamount;
...
}
When I run a make, I get this error at the end:
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
optimizer/built-in.o: In function `sys_optStopMeasure':
/source/trunk/linux-2.6.34/optimizer/sys_optStopMeasure.c:144: undefined
reference to `__divdi3'
Another person which has tried the code had no problems - he compiled
the code for a 64 bit machine. Can you explain to me the problem? Why
does the code work on 64 but not on 32 bit?
I've looked for some workarounds and found do_div(). Is this the way to
go? Or are there better ways?
Thanks for your help!
Andreas
--
To unsubscribe from this list: send an email with
unsubscribe kernelnewbies to ecar...@nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ
Information about some task_t members
Hello, could you give me some information about these members of the task_struct structure in sched.h? What do they mean? I have written down what I do understand ... hope you can give me some help. Kernel reading isn't that easy, there are so less comments... sleep_avg it has something to do with how long a task sleeps...?! timestamp timestamp, but what should it indicate? last_ran time when the task has last run sched_time perhaps the time when this task was last scheduled...? time_slice length of a time slice? ncvsw the number of voluntary context switches... nivcsw the number of involuntary context switches... Thanks in advance! Andreas -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Zone Questions
Hello, some questions to the zones. 1) Suppose I have a machine with 512 MB RAM. How is the memory node structured into zones? Is it in this way? ZONE_DMA: 1-16 MB ZONE_NORMAL: 17-512 MB That means, there is no high memory available for those machines with less than 896 MB RAM ? 2) Am I right that access to the kernel in memory is as follows: Virtual Memory - + + [kernel linear addresses] + + +---+ - 0xC000 [PAGE_OFFSET] + + + + + + + + [user-space lin. addresses] + + + + + + - - 0x Physical Memory - + + + + user + + +---+ + + kernel - - 0x So, user-space linear addresses are always below 0xC000 and if a user-process addresses something beyond this it is somehow prohibited. But in the real physical memory, the order is turned around: the kernel resides in the lower regions of the memory and the user-space in the upper regions. Is this correct? 3) Is ZONE_NORMAL used only for the kernel or also for user processes? 4) How much space is reserved for the kernel in the physical memory? 5) I've read something about min_low_pfn, max_low_pfn and max_pfn. So min_low_pfn is the first page frame number after the kernel (after _end). max_low_pfn gives me the last page frame number which is accessible by the kernel directly or in other words: the last page frame number which is used by the kernel for its data structures and so on, max_low_pfn+1 is the first page frame number of a user process. max_pfn is the last page frame number available in the physical address space. I've read this: In low memory machines, the max_pfn will be the same as the max_low_pfn. In which page frames are the user-level processes then stored? I must have misunderstood something... Thanks Andreas -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
Zone sizes with low memory
Hello, some questions to the zones. 1) Suppose I have a machine with 512 MB RAM. How is the memory node structured into zones? Is it in this way? ZONE_DMA: 1-16 MB ZONE_NORMAL: 17-512 MB That means, there is no high memory available for those machines with less than 896 MB RAM ? 2) Am I right that access to the kernel in memory is as follows: Virtual Memory - + + [kernel linear addresses] + + +---+ - 0xC000 [PAGE_OFFSET] + + + + + + + + [user-space lin. addresses] + + + + + + - - 0x Physical Memory - + + + + user + + +---+ + + kernel - - 0x So, user-space linear addresses are always below 0xC000 and if a user-process addresses something beyond this it is somehow prohibited. But in the real physical memory, the order is turned around: the kernel resides in the lower regions of the memory and the user-space in the upper regions. Is this correct? 3) Is ZONE_NORMAL used only for the kernel or also for user processes? 4) How much space is reserved for the kernel in the physical memory? 5) I've read something about min_low_pfn, max_low_pfn and max_pfn. So min_low_pfn is the first page frame number after the kernel (after _end). max_low_pfn gives me the last page frame number which is accessible by the kernel directly or in other words: the last page frame number which is used by the kernel for its data structures and so on, max_low_pfn+1 is the first page frame number of a user process. max_pfn is the last page frame number available in the physical address space. I've read this: In low memory machines, the max_pfn will be the same as the max_low_pfn. In which page frames are the user-level processes then stored? I must have misunderstood something... Thanks Andreas -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
