PutChar & GetChar

[Tim]

((y<<6 + y<<4) + x) << 1

Why bother with a mul if you don't have to

Why bother putting in obscure bit shifts if the compiler will do it for you? Any decent compiler will optimize ((y * 80) + x) * 2 to what you have above.

[Curufir]

Guess it's personal preference to assume as little as possible about the compiler's optimisation routines. If they're there then that's helpful, but I prefer to be explicit about exactly what I want the compiler to produce. It's a good point though Tim.

Hmm, df's problem.

Code: Select all

  mov bx, [y]
  mov dx, [width]
  mov ax, 0
  mov cx, [x]
.1
  shr bx, 1
  jnc .2
  add ax, dx
  nop
.2
  cmp bx, 0
  je .3
  shl dx, 1
  jmp short .1
.3
  add ax, cx
  shl ax, 1

With the result ending in ax. If things are that general MUL will always win out on cycles though (MUL is 13-26 cycles on 486 according to HelpPC).

**

That code seems right, but I wouldn't go using it. Anyhow the general principle should be plain to see.

[Pype.Clicker]

and why asking the compiler to optimize your "y*160" while you could remember it... Think about it: for the cost of only 2 bytes, you just store the start of the current line, and you perform a "next line" operation with "console.line_offset+=console.line_width". Now when you want to write a new char you just push it at

Code: Select all

*textram[line_offset+column_offset]=the_char;
*textram[line_offset+column_offset+1]=the_attributes;
column_offset+=char_size;

Try to remember that most of the time, you're adding chars one after another: a GOTOXY is rather an infrequent operation, so its optimization isn't that important.
Also, if you manage to do it, avoid to have a "putchar(c)" function but rather keep your "textram[...]" stuff in the main loop (repeating call/ret will decrease the throughput).

ALT: if you really want a "putchar" function, declare it "static __inline__" so that the compiler can do the better job with it.

[Perica]

..

[Whatever5k]

This putchar() function isn't really useful since you have to know x and y. You should replace this function which only takes the character (char c). A way to do this is to have a static int x and static int y which are both 0 at startup. On each putchar(), x is incremented. If the line is full, x is set to 0 and y is incremented...
Based on this more useful putchar(), you could easily implement printf() or printk() with:

Code: Select all

int printf(const char *format, ...)
{
   char buf[MAX];
   va_list arg;  /* you need to have the va_x functions
                        may copy these from linux sources
                      */
    int i = 0;

    va_start(arg, format);
    vsprintf(buffer, format, arg);  /* need vsprintf */
    va_end(arg);

    while(buffer[i] != '\0')
            putchar(buffer[i++]);

    return i;  /* return amount of printed characters */
}

[Perica]

..

[Whatever5k]

But i purposly put in the x and y Co-ordiantes, i think that having the x and y Co-ordinates there makes it even more handy

What? That should be handy? Sorry if I say this so directly, but the way you do it is crap! Consider your kernel is setting up paging or a file system for example and wants to print "done". How does it know where to print it? Why don't you make life easier?

[Perica]

..

[jrfritz]

I know how it could make it easy...if he did this:

void putch( char c, int x = curx, int y = cury )

He could use C++ and make a powerfull putch so you could use it two ways:

putch(c)
or putch( c, x, y ).

instead of making a putch that needs gotoxy.

[Pype.Clicker]

I know how it could make it easy...if he did this:

void putch( char c, int x = curx, int y = cury )

He could use C++ and make a powerfull putch so you could use it two ways:

I don't find it *that* powerful ...

Code: Select all

#define Putch(c) putch(c,curx,cury)

does the same ... and don't avoid the cost of recomputing x+y*line_width at every putch ...

[Perica]

..

[jrfritz]

GCC only makes PMode code.

[Perica]

..

[jrfritz]

Yea...

[Perica]

..