Stdargs and PDClib (previously weird screen)

[dh]

Ok, my system is back up.

I've been going through the PDClib and I found the va_args thing but there is a note about it being compiler specific. The basic question is: will it work with GCC 3.x ?


Cheers, DH.

[Solar]

I've been going through the PDClib and I found the va_args thing but there is a note about it being compiler specific. The basic question is: will it work with GCC 3.x ?

OK, looks like I have to improve the docs a bit at that point. And probably provide a _PDCLIB_config.h preconfigured for GCC in the v0.3 (which I fully intend to do anyway)...

The idea is that you take the stuff in _PDCLIB_config.h and replace it with whatever applies for your compiler. Having your compiler manual handy will help mucho.

In this case, that would be the Varargs chapter of the GCC Internals manual. Sorry, I haven't delved into it (just looked up the URL, real quick), so I can't say what you have to do. Other than trying the "default" implementation, using the strdarg.h provided by GCC, or waiting for PDCLib v0.3, that is.

[dh]

Thanks Solar.

I'm gonna download an "untainted" version (eg. one that RedHat hasn't make some "additions" to) and work from that.

Cheers, DH.

[Curufir]

Hmm, just scanned through that GCC 3 page and what it seems to be describing is a method of using internal compiler functions to make stdarg.h more machine independent.

If you're using an x86 machine then the PDClib version should work just fine.

The problems begin when compilers start passing arguments around using registers, or the arguments aren't aligned to the same size as a pointer. Neither of those problems should present themselves with GCC 3.0 on x86.

[dh]

ahh! Great Curufir! That's EXACTLY what I'm talking about. Well, in all the ASM code I have (about 30 lines ;P) all arguements are pushed onto the stack. And I highly doubt that I'll make use of any regesters to hold arguements as I'm trying to keep most of the code in C.

just a side question: about what is the overhead of pushing a value from a regester to the stack? (goal #3 = fast).

[Solar]

just a side question: about what is the overhead of pushing a value from a regester to the stack? (goal #3 = fast).

In the end, you won't have much choice in the matter, as it's the C compiler being responsible on exactly how parameters are parsed.

That being said, I honestly think the issue of stack vs. register stacking is neglectible when it comes to overall OS performance. After all, with the limited amount of x86 registers available, chances are that they will have to be saved or trashed by the function anyway.

Again, this is in the hands of the C compiler anyhow.

[dh]

ok, i understand.

[dh]

ok, i _think_ i got the stdarg.h implamented. (i threw all revelant stuff into one file) so now i gotta figure out how to use it ;P. don't tell me yet! haha, im trying to teach myself some.

@solar: i put in credit so don't think im taking it ;D

[Solar]

@solar: i put in credit so don't think im taking it ;D

The whole idea of providing a Public Domain C library is that you can do with it whatever you want.

[dh]

@Solar: Well, I'm just the kinda person who doesn't like not giving credit. I must say solar, you did a great job on it ;D.

I got exams though so I'm not working at the moment.

[Solar]

I must say solar, you did a great job on it ;D.

Pfff. Nothing in there but a couple of #defines and <string.h> (which is for the most part no-brainer stuff). Flatter me again when I've done stdio.h, stdlib.h and math.h.

[dh]

;D no problemo

[Candy]

Pfff. Nothing in there but a couple of #defines and <string.h> (which is for the most part no-brainer stuff). Flatter me again when I've done stdio.h, stdlib.h and math.h.

If you need any more help with math.h, I'm available again starting coming friday 17:00

[dh]

Just some foresight, I'm probably going to use a modified version of your libary for my "standard os" libary.