OSDev.org

the IO ports are always fixed in the same location starting from 0x3B0 onward, which means that a "base video port" is both useless and if taken by it's name should most likely not point to the CRTC registers.

BaseVideoPort = *(uint16_t *)0x0463;

static inline uint8_t ckPortInByte(uint16_t port)
{
	uint8_t ret;
	__asm__ ( "in %1, %0" : "=a"(ret) : "d"(port) );
	return ret;
}

static inline void ckPortOutByte(uint16_t port, uint8_t data)
{
	__asm__ ( "out %0, %1" : : "a"(data), "d"(port) );
}

__asm__ ( "in %1, %0" : "=a"(ret) : "d"(port) );
__asm__ ( "out %0, %1" : : "a"(data), "d"(port) );    // (0) doesn't work, of course

__asm__ ( "in %1, %0" : "=a"(ret) : "d"(port) : "memory" );
__asm__ ( "out %0, %1" : : "a"(data), "d"(port) : "memory" );    // (1) doesn't work

__asm__ __volatile__ ( "in %1, %0" : "=a"(ret) : "d"(port) );
__asm__ __volatile__ ( "out %0, %1" : : "a"(data), "d"(port) );    // (2) works

__asm__ __volatile__ ( "in %1, %0" : "=a"(ret) : "d"(port) : "memory" );
__asm__ __volatile__ ( "out %0, %1" : : "a"(data), "d"(port) : "memory" );    // (3) works

sortie wrote:You are doing an unaligned read to get the base video port. That is undefined behavior. Also, use the inline assembly from the wiki inline assembly example page.

sortie wrote:No need to yell. You are reading an uint16_t. Those must be 2-byte aligned in memory. However, the pointer you are reading it at is not 2-byte aligned (notice the hex value ends in a 3). That read is undefined behavior or UB. UB is toxic. Never do it, the compiler assumes it never happens, and code that rely on it end to break horribly when optimized. You really ought to do an online search for undefined behavior in C.

__asm__ ( "movw (0x0463), %0" : "=r"(BaseVideoPort) );

sortie wrote:No, because that doesn't solve the problem in a good way and because it demonstrates a critical misunderstanding on your part. You forgot to follow my advise and go an online search and find a good article such as http://blog.llvm.org/2011/05/what-every ... -know.html.

Mind that inline assembly is also UB if you lie to the compiler. That is, if you don't write it in exactly the correct manner (just adding volatiles is not enough, and sometimes they shouldn't even be there) the result is UB and bad things happen. Never write inline assembly, unless you are an expert in inline assembly. It's surprisingly hard to get right. Always reuse community-reviewed inline assembly such as the functions at http://wiki.osdev.org/Inline_Assembly/Examples or just use a regular assembly file.

The problem with UB is that it happens at the C compile level, not at the machine level. Unaligned reads are undefined behavior with gcc, even if the machine actually supports it. This is not a problem in practice, unless you write bad code such as your above example. (It's hard to make an unaligned pointer without invoking UB while doing so, well, I can think of a few ways but still). The solution is quite simply to turn your unaligned read into two smaller aligned reads:

Code: Select all

uint8_t* bda = (uint8_t*) 0x400;
uint16_t base_video_port = bda[0x63] << 0 | bda[0x64] << 8;

Notice how this does no unaligned reads and use exclusively well-defined behaviour. When you find yourself writing inline assembly, you should ask yourself whether it is possible to write well-defined C instead (you need to read that above link for information on UB to avoid this minefield). Mind that UB isn't the same as `platform-dependent' or `implementation-specified'. It means that the standard literally says that anything is allowed to happen. Thus a theoretical compiler that follows the standard is allowed to summon Darth Vader and have him destroy the compiler with a lightsaber whenever you do unaligned reads. The idea is that the compiler is allowed to define undefined behavior (if it wants to) as something implementation-specific, but it is not required to, and many C compilers do not do so in most cases.