Mail Archives: djgpp/2003/01/21/10:58:52
> It didn't (readme.1st didn't and FAQ neither did when I remember
> correctly from reading about symify there, bsdsymify wasn't
> mentioned, but wait; I'll have a look -- nope, no info -ahh, I could
> use info, but,... no, no time)
I wouldn't be surprised if it's not documented (or documented in a
non-obvious place). bsdsymify is relatively new.
> btw. that could be a suggestion for a djgpp documentation - and I
> might e-mail DJ delorie about it, but not now - every user usable
> program listed somewhere in one file with executable name, program
> purpose and full documenatiion of all commandline switches. That's
> actually all ones asks for the doc. of a command-line compiler. (and
> then there may be the FAQ with "what to do if?...")
That's what "info" is supposed to be. Every program should be
documented there, and each should have the command options listed
either on the main page or in a menu option named "Invoking" or
something like that.
Since DJGPP is a volunteer project, we'll always welcome help updating
the documentation (hint ;).
> Dynamic gotos are very nice: the best use is if jmp register is
> possible (so updating an register with the jump address) or by
> modyfying the memory place of the loaded executing code with the new
> wanted address.
I think if you try to do this, you'll end up fighting with gcc's
optimizer. If you want to do dynamic gotos, you really need to do
them the way gcc is expecting them, or write those parts in assembler.
> But "get "flag" from memory, cmp flag, jnz or whatever" is nearly
> the same as "get address from memory, jmp to address".
Right, but the most reliable way to do that is to have the address you
jump to be a function address, not a label within a function. Unless
you're doing dynamic gotos the gcc way.
> > > 3. is CLOCKS_PER_SEC the clock speed of the cpu, so for example
> > > 1,533,000,000 on an AthlonXP 1800+ ?
> >
> > RTFM. Or a C textbook.
>
> I got the Intel documentation of RDTSC already, but I'll look also
> for RTFM. Or you could have told me if you know.
If you look up clock() in the manual (RTFM = Read The F* Manual) it
tells you what CLOCKS_PER_SEC is. Or if you look at the comment for
CLOCKS_PER_SEC in <time.h> you'd see that it's a constant (91) so it
obviously isn't the CPU speed.
Type "info libc a clock" at the DOS prompt.
- Raw text -