va_args (va_start, va_end, va_list ) souce?

I'm trying to make a simplified printf that does not rely on stdarg.h and
its accompanying baggage, so I need the source to the va_args functions.
Including stdarg.h tends to pull in all sorts of extraneous library
functions.

The source for libgcc was my first guess, but good gravy, it could take a
year to unravel that stuff.

Does anyone have a clean va_args source to share, i.e., va_start, va_end,
va_list in source that would be compiler independent?

Scott



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4581 (20091107) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Op Sat, 07 Nov 2009 18:52:20 +0100 schreef Not Really Me
<>:
> I'm trying to make a simplified printf that does not rely on stdarg.h and
> its accompanying baggage, so I need the source to the va_args functions.

These are CPU dependent. Some arguments might be in registers, some might
be on the stack.



--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

On Sat, 07 Nov 2009 18:57:28 +0100, "Boudewijn Dijkstra"
<> wrote:

>Op Sat, 07 Nov 2009 18:52:20 +0100 schreef Not Really Me
><>:
>> I'm trying to make a simplified printf that does not rely on stdarg.h and
>> its accompanying baggage, so I need the source to the va_args functions.
>
>These are CPU dependent. Some arguments might be in registers, some might
>be on the stack.

Worse, this can also depend upon #pragma, extended keywords not
explicitly part of the c standard, and compile options, as well. For
example, parameters may be placed in an XRAM parameter stack on the
8051. Or passed in fixed static memory locations assigned and reused.
Also, parameters can be _spilled_ out of registers by the compiler if
their address is taken in the routine.

As you imply, the OP needs to disclose the compiler toolset and target
before getting closer to a meaningful answer.

Jon

Not Really Me wrote:
> I'm trying to make a simplified printf that does not rely on stdarg.h and
> its accompanying baggage, so I need the source to the va_args functions.

No can do. For starters, the va_args functionality consists of macros,
not functions. I.e. the bulk of it is _in_ <stdarg.h>. Trying to
implement a variadic function without it would be quite exactly like
trying to make omelettes without a pan.

> Including stdarg.h tends to pull in all sorts of extraneous library
> functions.

If so, that'll be because it has to.

Variable argument lists are pretty much by definition totally
system-specific. They depend on the compiler, the switches it was
invoked with, the operating system ABI, and all sorts of other things.

Jon Kirwan wrote:
> On Sat, 07 Nov 2009 18:57:28 +0100, "Boudewijn Dijkstra"
> <> wrote:
>
>> Op Sat, 07 Nov 2009 18:52:20 +0100 schreef Not Really Me
>> <>:
>>> I'm trying to make a simplified printf that does not rely on
>>> stdarg.h and its accompanying baggage, so I need the source to the
>>> va_args functions.
>>
>> These are CPU dependent. Some arguments might be in registers, some
>> might be on the stack.
>
> Worse, this can also depend upon #pragma, extended keywords not
> explicitly part of the c standard, and compile options, as well. For
> example, parameters may be placed in an XRAM parameter stack on the
> 8051. Or passed in fixed static memory locations assigned and reused.
> Also, parameters can be _spilled_ out of registers by the compiler if
> their address is taken in the routine.
>
> As you imply, the OP needs to disclose the compiler toolset and target
> before getting closer to a meaningful answer.
>
> Jon


grumble, grumble. I suppose you are both right. It really does have to be
processor/compiler specific. Sometimes it is only clear when someone else
points it out.

Thanks,
Scott



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4588 (20091109) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

On Sat, 07 Nov 2009 10:52:20 -0700, Not Really Me wrote:

> I'm trying to make a simplified printf that does not rely on stdarg.h and
> its accompanying baggage, so I need the source to the va_args functions.

They're macros, not functions. The fact that the second argument to
va_arg() is a type should be a clue (you can't pass a type as a function
argument).

> Including stdarg.h tends to pull in all sorts of extraneous library
> functions.
>
> The source for libgcc was my first guess,

Nope; try the source for gcc itself.

gcc's stdarg.h (it's part of gcc, not libc) defines them as:

#define va_start(v,l) __builtin_va_start(v,l)
#define va_end(v) __builtin_va_end(v)
#define va_arg(v,l) __builtin_va_arg(v,l)

the __builtin_* "functions" are rather like what Lisp calls "special
forms": neither functions nor macros, but constructs which the compiler
recognises and handles specially.

If you want to write equivalents, you need to know the details of the
platform's calling convention, i.e. which arguments will be in which
registers, which will be on the stack (and where).

If you're lucky, the compiler will just push all of the unspecified
arguments onto the stack in right-to-left order, so va_arg() is just
essentially "(*((type *)(ap))++)"; most x86 platforms behave like this. If
you're not so lucky, you will have to enumerate all of the possible
combinations of argument types until the registers have been exhausted
(after which, the rest will be on the stack).

Also, some platforms use a different calling convention for variadic
functions (e.g. Windows uses "cdecl" rather than "stdcall"), in which case
the convention for variadic functions is often simpler (e.g. pushing all
unspecified arguments onto the stack rather than using registers).

(Chris Giese) writes:

> "Not Really Me" <> wrote:
>
>>I'm trying to make a simplified printf that does not rely on stdarg.h and
>>its accompanying baggage, so I need the source to the va_args functions.
>>Including stdarg.h tends to pull in all sorts of extraneous library
>>functions.
>
> http://my.execpc.com/~geezer/code/printf.c
>
> This code assumes arguments on the stack. There are STDARG.H macro
> definitions in there, but be sure to check the assumptions I made
> with those.

Hi Chris,

Hey, that's the code I used in a lot of my own projects (after I dumped
newlib for small systems).

Thanks for making it available!

--

John Devereux

Chris Giese wrote:
> "Not Really Me" <> wrote:
>
>> I'm trying to make a simplified printf that does not rely on
>> stdarg.h and its accompanying baggage, so I need the source to the
>> va_args functions. Including stdarg.h tends to pull in all sorts of
>> extraneous library functions.
>
> http://my.execpc.com/~geezer/code/printf.c
>
> This code assumes arguments on the stack. There are STDARG.H macro
> definitions in there, but be sure to check the assumptions I made
> with those.

Thanks. It could be real useful in the future. My current project is using
Wind River Compiler for PPC and it uses registers for the first seven
arguments.

As others so helpfully pointed out, that is the reason the _va macros are
compiler specific.

Scott



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4595 (20091111) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

On Nov 11, 4:42*pm, "Not Really Me"
<sc...@validatedQWERTYsoftware.XYZZY.com> wrote:

> Thanks. *It could be real useful in the future. *My current project is using
> Wind River Compiler for PPC and it uses registers for the first seven
> arguments.
>
> As others so helpfully pointed out, that is the reason the _va macros are
> compiler specific.

Functions with variable number of arguments receive all their variable
arguments through stack. The <stdarg.h> macros dealing with accessing
the arguments on the stack are compiler (and possibly OS, because of
calling conventions) specific, but their purpose is simple enough -
walk through a stack frame.

On Nov 11, 6:28*pm, vladitx <vlad...@nucleusys.com> wrote:
> Functions with variable number of arguments receive all their variable
> arguments through stack.

That's compiler dependent and frequently not the case. Even on x86.

Steve