I have also heard of compilers (M$?) that have int = 64, long = 32 for x64, but that was a while ago.AJ wrote:On my i586-32 GCC Cross Compiler, char=8, short = 16, int = 32, long = 32, long long = 64.
On my x86-64 GCC Cross Compiler, char=8, short = 16, int = 32, long = 64, long long = 64.
Code: Select all
inline int inl(unsigned short port)
{
unsigned long ret_val;
asm volatile("inl %1,%0" : "=a" (ret_val) : "dN" (port));
return ret_val;
}
inline void outl(unsigned short port, unsigned long value)
{
asm volatile ("outl %0,%w1": :"a" (value), "Nd" (port));
}
You're wrong.Masterkiller wrote:The "long" type is strict 32-bit in size. You should use it instead of int.
Code: Select all
inline unsigned long inl(unsigned short port)
{
unsigned long ret_val;
__asm__ __volatile__("inl %%dx, %%eax" : "=a" (ret_val) : "dN" (port));
return ret_val;
}
inline void outl(unsigned short port, unsigned long value)
{
__asm__ __volatile__("outl %%eax, %%dx" : : "d" (port), "a" (value));
}
OK, I'm wrong, but it depends on the compiler. Every compiler include documentation of size of types. Once you compile an application there is no more long and int, there is 32-bit pointer (dword).Brynet-Inc wrote:You're wrong.Masterkiller wrote:The "long" type is strict 32-bit in size. You should use it instead of int.
http://en.wikipedia.org/wiki/64bit#64-bit_data_models
You should never assume that.. use Stdint types.
Another hardware device detection is done by BIOS just before loads the bootsector. If not clear the screen and hang the execution on the bootsector, you will see a table result of the PCI Scanning of the BIOS and other information. Last line contains the text "Verifying DMI Pool Data...". If you still get 0xFFFFFFFF value from reading BUS/DEVICE address listed in that table, you have an error in your program.Revelation wrote:But I still get FFFF as return value. I still haven't got a clue what could cause this. Should I initialize something before doing this scan procedure?