Writing own printf function without using stdarg.h

[osfreak]

Hi,

I am trying to write my own printf function . I dont want to use the stdarg.h since i am going to use this function in real mode (during booting). So i need to access the arguments from memory directly.

I want to understand how the arguments are stored when they are passed to the stack. I am using the gcc compiler on linux to compile and run my programs ..

I already have routines to print short, long, int and characters. This is how i plan to implement my function :

int printf(char *str,...)

Sample call : printf ("%c%d",'a',45)

In printf , I will have the address of the string str so I will scan that and count the number of arguments and their types. Now using this information and the address of the first argument str, I need to get access to the other arguments on the stack .

I dont want to add checks and just want basic functionality.

Any help is appreciated.

[User Name:]

GCC doesn't support real mode. I suggest you do what's required to be done in rm in asm, then get to pm and call your C code.

[osfreak]

GCC doesn't support real mode. I suggest you do what's required to be done in rm in asm, then get to pm and call your C code.

Thanks for the reply.

I knw it doesnot support. I will compile using bcc (16-bit compiler) link it to my rountines in ASM and call c functions.
The basic putchar function is written is ASM and i have used this putchar to write other routines like prints for string, and printd for printing integers.

Now i need to write the printf rountine in C and call from ASM also to ease outputting to the screen.

Reply back if not clear. I'll provide more info .

[osfreak]

When GCC calls your function, it pushes all its arguments onto the stack, starting with the last one, then issues a call. This means that, on entry to your function, the stack is laid out like this:

Last argument
...
4(%esp) First argument
(%esp) Return address
Sizes and layouts of individual arguments are as follows:

Integers up to 32 bits and pointers are pushed as a single longword.
long long int is pushed as two longwords; the least significant is pushed last (and so is located first in memory).
float and double are pushed as a double-precision value, occupying 8 bytes.
long double is pushed as an extended-precision value followed by 2 bytes of padding, totalling 12 bytes.
As before, structures are more complicated and best avoided.
These rules also apply to functions which take a variable number of arguments (like printf). As with any variadic function, the function must find its own way of determining how many arguments were actually passed (usually based on one of the required args).


Now taking the above abstract in mind:
why doesnt my code work :


int testfn (int c,int v, int w)
{
printf("%d\n",*(&c));
printf("%d\n",*(&c+4));
printf("%d\n",*(&c+8));
}
int main(){
testfn(34,45,56);
}

Output:
34
junk
junk

[cas]

In the future, please surround your code with code tags.

Now taking the above abstract in mind:
why doesnt my code work :

It doesn't work because you've forgotten that pointer arithmetic scales by the size of the pointed-to type. Say an int is 4 bytes wide. A pointer to int plus 4 adds on 16 bytes (that is, 4 integers), not 4 bytes (which is one integer). So you probably want to try &c + 1 and &c + 2.

[User Name:]

What's wrong with stdarg.h? Here's a link to my slightly flawed implementation of prinf and vprintf: My vprintf

[maxorator]

In the future, please surround your code with code tags.

It doesn't work because you've forgotten that pointer arithmetic scales by the size of the pointed-to type. Say an int is 4 bytes wide. A pointer to int plus 4 adds on 16 bytes (that is, 4 integers), not 4 bytes (which is one integer). So you probably want to try &c + 1 and &c + 2.

Isn't an integer 2 bytes anyway in 16-bit compiler?

What's wrong with stdarg.h? Here's a link to my slightly flawed implementation of prinf and vprintf: My vprintf

Did you read his post? In real mode you can't use C standard library.

[grumpy]

Isn't an integer 2 bytes anyway in 16-bit compiler?

Not necessarily. The "16-bit" in the term "16-bit compiler" has variable meanings (i.e. different people will tell you it means different things). However, a relatively common meaning is that the "16-bit" refers to accessible address space - for example, the default size of a pointer.

A 16-bit system will often support a 16-bit integer type, but that is coincidental - it is not unheard of for "int" supported by a 16-bit compiler to be 32-bit. Some older 16-bit compilers also allowed configuring (eg via command line options) the size of an int type.

One practical reason that an int can be the same size as either a short or a long (and potentially both) was to allow for some oddball 16-bit compilers.

[cas]

Isn't an integer 2 bytes anyway in 16-bit compiler?

But even if that's the case, it doesn't matter. The point isn't that ints are 2 bytes, it's that they aren't (guaranteed to be) one byte.

[User Name:]

You'll never have a one byte arg on the stack anyway. Pushing a byte is impossible, and even thought it is possible to manipulate sp to emulate it, it is standard for compilers to push chars as 2 or 4 bytes.