I know a very optimized way to print characters in pmode

[Skirox]

Code: Select all

void clrscr();
void putch(char c,unsigned char x,unsigned char y,unsigned char fore,unsigned char back);
void putch(char c,unsigned char x,unsigned char y,unsigned char fore,unsigned char back)
{
    *((unsigned short*)(0xB8000+(x*80+y)))=c|(((back<<4)|(fore&0x0F))<<8);
}
void clrscr()
{
    int i;
    for(i=0;i<80*25;i++)
    {
        *((unsigned short*)0xB8000+i)=(0x20|(((0<<4)|(15&0x0F))<<8));
    }
}

[piranha]

...and your point is...?

-JL

[Nessphoro]

/thread

[Skirox]

... to help noobies

[Nessphoro]

It's on the wiki, and in many tutorials.
ex. Jammes Molloy

[Skirox]

... but mine is more optimized and takes less memory.

[Solar]

... but mine is more optimized and takes less memory.

As for optimizing, that code could do with a couple of spaces, and a linebreak or two.

As for "taking less memory", how do you figure?

All in all, I prefer the versions already in the various tutorials, any time. Mallory's code could move attributes, color etc. out of the functions and make them constants, but other than that I see no need for "optimizations" there.

Anyway, I don't think that code (writing to video memory directly) sees much use anyway, much less in the critical path of anything.

[Skirox]

When I'm saying "optimizing", I mean creating fewer variables and writing code that uses constant values (using values directly), which will take less memory.

[NickJohnson]

You realize that arguments also take memory on the stack, right? Of course, this doesn't matter at all anyway, because the tiny amount of memory you use for a handful of local variables is negligible.

[AJ]

Well, not really.

Your code has no variables defined other than in your function prototypes. These still end up on the stack (x86) or in registers (IA64). You simply shift the onus of storing the values of x and y and the colour attributes on to the caller, which presumably still has to store these values in global/static variables anyway (for keeping track of the cursor position etc...).

In addition you lose the benefit of a variable name for the video memory buffer, instead replacing it with a magic number. For the ease of others using your code (especially newbies who you are trying to help), you will now be required to provide a comment of explanation.

I don't see the point.

Cheers,
Adam

[edit: beaten to it!]

[Solar]

When I'm saying "optimizing", I mean creating fewer variables and writing code that uses constant values (using values directly)...

...which is called "magic numbers" and generally frowned upon, because maintainability of the source goes to hell.

That's what constants are for.

...which will take less memory.

...again, how do you figure?

I took the liberty of optimizing your code further:

Code: Select all

// High byte is the text attribute (see TEXT_ATTRIBUTE below),
// low byte is the character ASCII code.
static unsigned short * const VIDEO_MEM = (unsigned short *) 0xb8000;

// FIXME: Extend this to a complete list of color codes.
static unsigned short const COLOR_white = 15;
static unsigned short const COLOR_black = 0;

// Use this macro with the COLOR_* constants above to get the
// desired text attribute high byte (high nibble is background, low
// nibble is foreground color). To get the value to write to the
// VIDEO_MEM array, binary-OR this macro with the character
// ASCII code.
#define TEXT_ATTRIBUTE( foreground, background ) ( ( ( ( background ) << 4 ) | ( ( foreground ) & 0x0f ) ) << 8 )

// FIXME: Bad design, as this puts the burden of keeping track
// of "current" cursor position on the caller.
void putch( char const c, unsigned char const pos_x, unsigned char const pos_y, unsigned char const foreground, unsigned char const background )
{
    VIDEO_MEM[ pos_x * 80 + pos_y ] = c | TEXT_ATTRIBUTE( foreground, background );
}

void clear_screen()
{
    for ( int i = 0; i < 80 * 25; ++i )
    {
        VIDEO_MEM[i] = ' ' | TEXT_ATTRIBUTE( COLOR_white, COLOR_black );
    }
}

It yields exactly the same object code as your clrscr() source does (tested with gcc -std=c99 -O3 | strip)...

Edit: Beaten twice, but I gotz codez.

[gerryg400]

The best optimisation you can make is to change all those unsigned chars to ints. It will reduce your code size by 60% and perhaps double the speed of the putch function.

[Edit] Oops, it's not quite that big an improvement. I was fooled because GCC decided to inline the function and at that point didn't continue optimising it. Tried again with inlining turned off and the improvement is only about 20% size improvement.

[Karlosoft]

However your clrscr is not so optimised... It is slower than a good implemented memset function

[bluemoon]

Code: Select all

*((unsigned short*)0xB8000+i)=(0x20|(((0<<4)|(15&0x0F))<<8));

First, you may need volatile keyword here...

Second, practically most pmode OS rearranged the address space, in my debug print function I use:

Code: Select all

int kputc(int c) {
   volatile unsigned char * video = (volatile unsigned char*) (KERNEL_1M + 0xB8000);
   ...
}

Furthermore, for a console driver it better ask the kernel with something like void* GetMappedAddress((void*)0xB8000) upon initialization, and don't hard-code the address.

[Solar]

Code: Select all

*((unsigned short*)0xB8000+i)=(0x20|(((0<<4)|(15&0x0F))<<8));

You may need volatile keyword here...

Hmmmm... why?