Synchronizing multiple clocks of varying frequencies

[anomie]

test.c:5: error: `for' loop initial declaration used outside C99 mode

Try "gcc -std=c99" to force C99 rather than C89 (really gnu89). Or #define _ISOC99_SOURCE should work.

[Nach]

Hmm that did work. Then why is it labling it as not C99 compliant?

[Noxious Ninja]

Wouldn't that error mean it IS a C99 construct, but the compiler is not in C99 mode when compiling it?

[Nach]

Wouldn't that error mean it IS a C99 construct, but the compiler is not in C99 mode when compiling it?

Ah yes, you're right.

Older GCCs had a different error for that, and it was quite weird.

[bztunk]

I just found out, I think, why inlining wasn't complete for the thread starter: inline functions (at least C99 ones) are marked broken in GCC!
http://gcc.gnu.org/c99status.html

If GCC didn't implement all of C99, I wonder who did :D

[Nach]

If GCC didn't implement all of C99, I wonder who did

http://www.comeaucomputing.com/

I am quite suprised to read about variable length arrays in C99 from that link you provided. Would really change how we program. Many uses of linked lists and dynamic memory would no longer be the ideal or only way "to do it"...

[bztunk]

http://www.comeaucomputing.com/

Wow, a commercial vendor who is conforming to standard, I got my faith in humanity back :D

I am quite suprised to read about variable length arrays in C99 from that link you provided. Would really change how we program. Many uses of linked lists and dynamic memory would no longer be the ideal or only way "to do it"...

Well, "how" isn't all programmers I hope :D In C++, there's that nice thing called std::vector.

And of course, it's near certain that variable length arrays do use dynamic memory. You just don't see it.

[Nach]

In C++, there's that nice thing called std::vector.

I'm aware, use it all the time. I even have ZSNES using it
http://cvs.sourceforge.net/viewcvs.py/z ... iew=markup

C however is the discussion where that's not available.

And of course, it's near certain that variable length arrays do use dynamic memory. You just don't see it.

But of course. It just means no longer needing to rip your hair out worrying if you free'd that last malloc or if you're too early.

[bztunk]

I'm aware, use it all the time. I even have ZSNES using it
http://cvs.sourceforge.net/viewcvs.py/z ... iew=markup

C however is the discussion where that's not available.

But of course. It just means no longer needing to rip your hair out worrying if you free'd that last malloc or if you're too early.

I just wanted to clear things up :D

[byuu]

Neat, so inline doesn't work in anything I'd ever use. Guess I'll stop even bothering with it then.

Not to bore anyone, but this is my way of dealing with variable-sized arrays, specifically for strings and lists of strings:

I never liked using C++ only features. The only thing I use are classes when I need two or more of the same struct.
My workaround for std::vector/variable-arrays was my own class that does basically the same thing with a preference for speed over memory usage, so it doubles the array everytime its size limit is exceeded. It manages a list of pointers.
I use a struct instead of a class that does this for individual strings, and then wrote wrapper functions for 80% of libc, threw in 80% of PHP functions (split, replace, ...), and then made a few of my own. Combined the two for the equivalent of char string[...][...]. I'll probably make the vector-list use structs as well.
It's nice because I don't bind any weird crap to it like using ->.<><<>>:: around functions, or having to show a string is really a class with stuff like string.split(char *str), instead I wrap everything like this: int strcmp(string *a, char *b), int strcmp(string *a, string *b), etc.

[Nach]

Neat, so inline doesn't work in anything I'd ever use. Guess I'll stop even bothering with it then.

It does work, just make sure the file is compiled in a C++ compiler as C++. MSVC or g++ work fine.

My workaround for std::vector/variable-arrays was my own class that does basically the same thing with a preference for speed over memory usage, so it doubles the array everytime its size limit is exceeded. It manages a list of pointers.

Why are you reinventing the wheel? FYI, you can configure how std::* works with certain functions. Their implementation is probably faster than yours.

I use a struct instead of a class

Exact same thing.

that does this for individual strings, and then wrote wrapper functions for 80% of libc, threw in 80% of PHP functions (split, replace, ...), and then made a few of my own.

You mean throw in C++ functions using your own implementation for no real reason.

It's nice because I don't bind any weird crap to it like using ->.<><<>>:: around functions

Oh no, it operator overloads, it's the end of the world.
Did you know that most of the overloaded operators in std::* have a function name as well if you prefer that? For example, std::string has + and append().

instead I wrap everything like this: int strcmp(string *a, char *b), int strcmp(string *a, string *b), etc.

If you need the wrappers so much, just add them to the std::* family, and using templates, it'll be easier.


I really don't understand why you would go out of your way to create something new which already exists standardized with all modern compilers which you then have to bug test and isn't as featureful.

[parasyte]

My workaround for std::vector/variable-arrays was my own class that does basically the same thing with a preference for speed over memory usage, so it doubles the array everytime its size limit is exceeded.
[...]
It's nice because I don't bind any weird crap to it like using ->.<><<>>:: around functions, or having to show a string is really a class with stuff like string.split(char *str), instead I wrap everything like this: int strcmp(string *a, char *b), int strcmp(string *a, string *b), etc.

Couple things...

First, std::vector already doubles the size when capacity is exceeded.

Second, if you hate template syntax (and many do), you can simply typedef it away to avoid having to specify that sort of thing all the time. Then again, that's more useful when there are several template arguments, and std::vector only requires one (unless you really want to use pthread_alloc over the default alloc).

[byuu]

Why are you reinventing the wheel?

Because I can, mostly. And because it's easier to make something with the tools I know than to learn a bunch of new C++ paradigms that rely on an STL. It's my preference, and I wasn't saying you were wrong for doing things your way.

Exact same thing.

...hardly. A struct is just a contigious block of memory that can be malloc'ed, typecasted into an array, that can be set to an arbitrary memory location to read structured elements from it, etc. etc.
A class is a dynamic element where C++ has to use wrappers and 'behind-the-scenes' functions to reuse the same class function for all defined classes. It can only be created via new/delete operators, or by declaring it at runtime. new/delete may be similar to malloc/free, but malloc/free has more flexibility as a direct memory block, and is much easier to typecast and manage (e.g. with a malloc/free overload that keeps track of memory leaks).
I also don't need the function capabilities, have no use for public/overloaded structs, nor public/private declarations, nor virtual function overloads. Using a class for everything is like using a semi to move any kind of object from one place to another. Why use the semi when a car works just fine? My point was that I do take advantage of c++ when I feel it's appropriate, but I usually just stick to structs for most things. I also get the fun advantage of not requiring c++ nor the STL for my programs to run when I don't make my libraries rely on c++ constructs. If a programmer chooses to use my library to create an application that's 100% ansi-c or 100% ansi-c++, my library can now do both.

You mean throw in C++ functions using your own implementation for no real reason.

I wasn't aware that C++ had functions to turn string math to integers ("2+5*(6+2)" = 42), split strings into arrays via specified token, and replace strings where the key and token are of different lengths? Do tell me what those functions are.

Oh no, it operator overloads, it's the end of the world.

What's with the confrontational attitude? I don't personally like breaking standards. c's string functions worked just fine, there was no reason to make cout/cin use << and >>, likewise with other c++ aspects.
cout("x = ", x); would've worked just as good, and still been equally as less powerful as printf with its formatting capabilities.

Did you know that most of the overloaded operators in std::* have a function name as well if you prefer that? For example, std::string has + and append().

No, but good to know.

If you need the wrappers so much, just add them to the std::* family, and using templates, it'll be easier.

I really don't understand why you would go out of your way to create something new which already exists standardized with all modern compilers which you then have to bug test and isn't as featureful.

I don't want to use templates as a personal choice to maintain ansi-c support (I know, I need to make my vector class use structs first for this to work), it took me about 2 days to make the string library in question, and personally I find it a lot more powerful than anything c/c++ has for string parsing. I even have a sprintf function that is size-safe. No worries about buffer overflows.
Also, to me: easier is using something I already know to accomplish something. Easier is not learning a totally new syntax-style of programming to accomplish the same goal. In the latter, it would be easier to just use PHP to format/parse text.

First, std::vector already doubles the size when capacity is exceeded.

Awesome, so then my idea was identical to std::vector. That means std::vector is no better at memory management than I already am. Rocking.

I don't even know what you're talking about in the second part of your post, my apologies.

---

Anyway, I don't care for an argument about why c++ is better than c, or vice versa. I learned c first, so I'll always have an illogical preference to using it over c++ when I can, and likewise to c++ zealots over c.
I try my best to use each when they're appropriate, and realize when one is better than the other for me personally. No reason to get upset about it, I'm not forcing you to stop using classes and templates for your applications.

[Nach]

Why are you reinventing the wheel?

Because I can, mostly. And because it's easier to make something with the tools I know than to learn a bunch of new C++ paradigms that rely on an STL. It's my preference, and I wasn't saying you were wrong for doing things your way.

Yes it's your preference, but then again it is reinventing the wheel. If you'd learn how to use the STL effectively, you'd probably create programs much faster when you see you need some type of functionality that the STL provides. Very useful if you have a deadline for something.

Exact same thing.

...hardly. A struct is just a contigious block of memory that can be malloc'ed, typecasted into an array, that can be set to an arbitrary memory location to read structured elements from it, etc. etc.
A class is a dynamic element where C++ has to use wrappers and 'behind-the-scenes' functions to reuse the same class function for all defined classes. It can only be created via new/delete operators, or by declaring it at runtime. new/delete may be similar to malloc/free, but malloc/free has more flexibility as a direct memory block, and is much easier to typecast and manage (e.g. with a malloc/free overload that keeps track of memory leaks).

No. You're comparing a C struct to a C++ class. In C++ a class and struct are EXACTLY the same except the default if members are public or private. In C++ if you created any object, and specified every segment as public, private, or protected yourself there would be 0 difference if the variable was declared as a struct or class.

I don't really see where your memory allocation argument came in from. Also, you can't overload any operator or function name in C. And C++ also allows you to overload new/delete for different objects.

I also don't need the function capabilities, have no use for public/overloaded structs, nor public/private declarations, nor virtual function overloads.

So then you don't use it. But saying oh it's better because I used the name struct to declare instead of class doesn't really make much sense.

Using a class for everything is like using a semi to move any kind of object from one place to another. Why use the semi when a car works just fine?

They're both the semi or the car depending how you use it. Neither one of them intristicly has an advantage or disadvantage to the other.

My point was that I do take advantage of c++ when I feel it's appropriate, but I usually just stick to structs for most things.

You'd probably take much better advantage of C++ if you learned more about how it works and to use it effectively. And yes that's not easy, I've been studying the STL for a while now and still don't feel I've come close to mastering it yet.

I also get the fun advantage of not requiring c++ nor the STL for my programs to run when I don't make my libraries rely on c++ constructs. If a programmer chooses to use my library to create an application that's 100% ansi-c or 100% ansi-c++, my library can now do both.

Yes, if you're aiming for a library to use with C programs it's best to write in C so you don't need wrappers.

You mean throw in C++ functions using your own implementation for no real reason.

I wasn't aware that C++ had functions to turn string math to integers ("2+5*(6+2)" = 42)

Neither does C for that matter. But you can easily find C++ libs on line for that instead of needing to write your own. I think Boost has an expression parser. And I think Bisqwit has an extremely powerful expression parsing lib on his site that even allows you to work with algebra type variables.

split strings into arrays via specified token

Easy as pie.

Code: Select all

void Tokenize(const string& str, vector<string>& tokens, const string& delimiters)
{
  //Skip delimiters at beginning.
  string::size_type lastPos = str.find_first_not_of(delimiters, 0);
  
  //Find first "non-delimiter".
  string::size_type pos     = str.find_first_of(delimiters, lastPos);

  while (string::npos != pos || string::npos != lastPos)
  {
    //Found a token, add it to the vector.
    tokens.push_back(str.substr(lastPos, pos - lastPos));
    
    //Skip delimiters.  Note the "not_of"
    lastPos = str.find_first_not_of(delimiters, pos);
    
    //Find next "non-delimiter"
    pos = str.find_first_of(delimiters, lastPos);
  }
}

Can you really write a variable length self allocating/deallocating tokenizer in less than 10 lines of code without using the STL?

and replace strings where the key and token are of different lengths? Do tell me what those functions are.

Off course, std::string.replace()

Oh no, it operator overloads, it's the end of the world.

What's with the confrontational attitude? I don't personally like breaking standards. c's string functions worked just fine, there was no reason to make cout/cin use << and >>, likewise with other c++ aspects.
cout("x = ", x); would've worked just as good, and still been equally as less powerful as printf with its formatting capabilities.

I'm not trying to confront, but you seem to bash operator overloading for no reason.

There is a perfectly good reason to use << and >>.

Code: Select all

*output << "---------------------Internal ROM Info----------------------\n"
        << "       File: " << RemovePath(filename) << "\n"
        << "       Name: " << InternalName         << "  Company: " << Company[CompanyByte] << "\n"
        << "     Header: " << HeaderBuffer         << "     Bank: " << ROMBank << "ROM\n"
        << "Interleaved: " << IAlgNames[IntType]   << "     SRAM: " << SRAM << " Kb\n"

Can you write that using the parameter list that it looks as good? With << I can see exactly how the output will look, no need trying to match up escape sequences with parameters later.

The printf way of doing things with escape sequences and variable amount of parameters is also extremly dangerous. Do you realize how many programs are compromised because someone sent an attack to it?

Take this simple program:

Code: Select all

fgets(buffer, buffer_len, stdin);
printf(buffer);

Pass the input line something with a % in it and blow the program to kingdom come. Being creative you can even stack smash the program and embed your own code to take over the machine.

Mistakes like this are made all the time. Yet it would be impossible to write the same code with this mistake in C++.

Code: Select all

cin.getline(buffer, buffer_len);
cout << buffer;

If you need the wrappers so much, just add them to the std::* family, and using templates, it'll be easier.

I really don't understand why you would go out of your way to create something new which already exists standardized with all modern compilers which you then have to bug test and isn't as featureful.

I don't want to use templates as a personal choice to maintain ansi-c support (I know, I need to make my vector class use structs first for this to work), it took me about 2 days to make the string library in question, and personally I find it a lot more powerful than anything c/c++ has for string parsing. I even have a sprintf function that is size-safe. No worries about buffer overflows.

Still you had to waste two days making it. And are you so certain it's bug free? If you wanted size safe strings in C, use the safestr library.

http://www.zork.org/safestr/

I quote why it's so good:

Code: Select all

The goal of the SafeStr library is to provide a rich string-handling library for C that has safe semantics yet interoperates with legacy library code in a straightforward manner. Additionally, porting code that uses standard C string handling should be straightforward. The library should work on all modern Unix-like platforms, as well as any 32-bit Microsoft Windows OS.

The overt security goals of the library are as follows:

   1. Buffer overflows should not be possible when using the API.
   2. Format string problems should be impossible when using the API.
   3. The API should be capable of tracking whether strings are "trusted", a la Perl's taint mode.

The API is meant to provide rich functionality and be easy to use, all the while improving security. 

Also, to me: easier is using something I already know to accomplish something. Easier is not learning a totally new syntax-style of programming to accomplish the same goal. In the latter, it would be easier to just use PHP to format/parse text.

Still doesn't explain why you reinvented the wheel instead of using a lib.
And you'd probably gain a lot if you'd just take the time to learn C++.

First, std::vector already doubles the size when capacity is exceeded.

Awesome, so then my idea was identical to std::vector. That means std::vector is no better at memory management than I already am. Rocking.

Very far from the truth. Just because you allocate memory in a similar manner doesn't mean you did it better. The STL was written by a group of people using the most advanced algorithms that you would probably never even think about. There's a lot more to it than you might consider at first.

I'll give a quick easy real life example.

I wrote a function to calculate exponents using the most straight foward optimized manner and couldn't dream of it being written better.

Code: Select all

inline unsigned int npow(register unsigned int base, register unsigned int exponent)
{
  if (!exponent) { return(1); }
  register unsigned int total = base;
  while (--exponent)
  {
    total *= base;
  }
  return(total);
}

Then someone showed me how they out did me using a more complicated but more advanced algorithm which signifigantly saves time on larger exponents.

Code: Select all

inline unsigned int npow(register unsigned int base, register unsigned int exponent)
{
  if (!exponent) { return(1); }
  register unsigned int i, total;
  for (i = 2, total = base; i < exponent; i += i)
  {
    total *= total;
  }
  for (i >>= 1; i < exponent; i++)
  {
    total *= base;
  }
  return(total);
}

Realize the entire STL is like that, and odds are you did not write anything close to equal vector implementation.

Anyway, I don't care for an argument about why c++ is better than c, or vice versa.

Don't argue about it, instead really learn and understand both so you know exactly when to use which one.

I try my best to use each when they're appropriate, and realize when one is better than the other for me personally. No reason to get upset about it, I'm not forcing you to stop using classes and templates for your applications.

I'm not upset about it, and I'll only use classes or templates where I find appropriate, I'm trying to broaden your perspective, since it's obvious you really haven't studied the differences between them.

[funkyass]

I find this funny.

It doesn't really matter how strictly you stick to c or c++ in library writing. at the end of the day, a function is a just a pointer, and arguments are just words in memory.

so byuu is writing is own mini version of the STL. Nothing prevents potential users of his library from using the STL.

even tho you can still use strtok in C++.

[byuu]

In C++ a class and struct are EXACTLY the same except the default if members are public or private.

Then I stand corrected. Wow, that seems like a bad idea, though. Since a C struct is just a solid block of memory, nothing has to be done when accessing it. But with a C++ class, it has to do quite a bit more (like casting virtual pointers, casting the class over a function [don't know how it does it] so that the same function can be used by multiple classes, etc.). I'm sure most of that overhead won't even be needed if you only use variables in a class anyway, but still...

Also, you can't overload any operator or function name in C.

I was meaning typecasting.
typedef struct {
char sig[8];
byte value;
}s;
s *my_s;
char *buffer = (char*)malloc(sizeof(s));
fread(buffer, 1, sizeof(s), fp);
my_s = (s*)buffer;
printf("%s, %d\n", my_s->sig, my_s->value);

Can you do that with a class? You probably could, I admit I don't really know a lot about c++. I would assume the class operates a lot differently in the background...

But saying oh it's better because I used the name struct to declare instead of class doesn't really make much sense.

For C++, that's exactly correct; since, as you said, classes and structs are identical.

You'd probably take much better advantage of C++ if you learned more about how it works and to use it effectively. And yes that's not easy, I've been studying the STL for a while now and still don't feel I've come close to mastering it yet.

True, and true again. I admit a bit of apathy in not wanting to learn c++ templates and the STL. I really don't like it. I like traditional c much more, so I design my code to work like c would. It's really just a preference, and I mean -- I like to code. I don't care about getting something done in half the time, I like doing things my way and getting them to work exactly how I want them to. Yeah it took me two days to write that string library, but I know exactly how to use it, added a bunch of neat functions (all of my routines also have an equivalent that ignores text inside quotes, for example) that I like, and I've been able to reuse it in many projects; from cross assemblers to an emulator to a desktop shell replacement.
No, I can't guarantee it's bug free, but I've never had it crash and I've used it to assemble over 200kb of code. There's probably still bugs, I'll fix them as I find them, like any code.

Neither does C for that matter. But you can easily find C++ libs on line for that instead of needing to write your own.

Yeah, and this is where people really disagree with me a lot. I like my projects to use my code and base OS API only. I don't like using zlib, nor "Johnbob's c++ string library", or anything else. Mostly because, as I said, I like programming. And I don't like learning new APIs all the time. I can't keep those things straight unless I write them myself or use them everyday. I've written over 200kb of Direct3D code, and as of right now, I haven't a clue how any of it works because I've forgotten the massive API set and how it works.
This also gives me the advantage of flexibility. If I use some third-party string library, and it ends up having a bug and it crashes, it would be a lot harder for me to fix it. If I wanted to add functionality to it, I would have to figure out how the library works first to add my functionality in correctly. It's just easier for me to "reinvent the wheel", and I enjoy it. I think most people would agree that the code I produce is solid and clean, despite my bizarre approach to programming.

Can you really write a variable length self allocating/deallocating tokenizer in less than 10 lines of code without using the STL?

Yeah. Since your code has behind-the-scenes self-allocation/deallocation code, so too should mine be able to do the same. strcpy() below checks the size of the string before copying and reallocates as needed:

Code: Select all

void split(stringlist *dest, char *key, char *src) {
int i, ssl = strlen(src), ksl = strlen(key), lp = 0, split_count = 0;
  for(i=0;i<=ssl-ksl;) {
    if(!memcmp(src + i, key, ksl)) {
      strcpy(dest, split_count++, src + lp, i - lp);
      i += ksl;
      lp = i;
    } else i++;
  }
  strcpy(dest, split_count, src + lp);
}

Your point is taken, though.

I'm not trying to confront, but you seem to bash operator overloading for no reason.

It is solely for the reason that I like traditional c syntax more. I don't like the idea of operator overloading.

Can you write that using the parameter list that it looks as good? With << I can see exactly how the output will look, no need trying to match up escape sequences with parameters later.

No, but I can make mine format correctly, without having to ensure that InternalName, HeaderBuffer, and IAlgNames[IntType] are all the same width when copied into output.
I've kind of gotten used to printf's syntax by now, but I admit a better one could be created. I've always thought a cross between printf and cout would be best.
sprintf(output, "x = ", %2d:x);
Yeah, I know. Made up operator, evil.

The printf way of doing things with escape sequences and variable amount of parameters is also extremly dangerous. Do you realize how many programs are compromised because someone sent an attack to it?

Just because other programmers are stupid, doesn't mean I am.
Your example program wouldn't crash my string library. Only sending it a buffer over 2gb in size would cause it to truncate the string.
I read file data using fread/fgetc only, into memory I allocate based on the size of the file, and when I pass it to be copied into a string, the API that is called makes sure that the data it is copying is shorter than the string it is copying to, or it reallocates.

Mistakes like this are made all the time. Yet it would be impossible to write the same code with this mistake in C++.

I take serious question with the phrase 'impossible', but I will accept that you could write c++ code that would make the above attack impossible while accomplishing the same thing, much as I've done in c -- albeit with a lot more work on my part than yours.

Very far from the truth. Just because you allocate memory in a similar manner doesn't mean you did it better.

True, I can't compete against some peoples' optimizations, but I'm not really too worried about speed for a string library. Again though, your point is taken. I've explained above why I don't like using third party code libraries nor the STL.

I'm not upset about it, and I'll only use classes or templates where I find appropriate, I'm trying to broaden your perspective, since it's obvious you really haven't studied the differences between them.

That's correct. I've studied c++ a lot on and off, but never really delved into it. I am happy with c, and can do anything I want in it, without requiring c++ functionality. But I'm slowly getting used to using some of it, like classes. I seriously doubt I will ever embrace templates and namespaces, though; useful as they may be.

It doesn't really matter how strictly you stick to c or c++ in library writing. at the end of the day, a function is a just a pointer, and arguments are just words in memory.

I compile my libraries directly into the executable. I don't create object files to statically link into the program at compile time, but I very easily could, yes.
If you ever dabble around with RTOS/hobbyist OS development, a lot of them don't even have an STL implementation, so C++ code won't work. Whereas C code does, since it's just a direct translation from c->x86, with no runtime environment/"whatever the hell the STL requires/does" required to run the code. A lot of OSes write all of their low-level kernel code in C only for this reason. This is irrelevant to my string library of course, just an example.

[anomie]

Then I stand corrected. Wow, that seems like a bad idea, though. Since a C struct is just a solid block of memory, nothing has to be done when accessing it.

And if you create a POD struct, it'll still be that way. Same for a POD class. OTOH, in C++ you can add constructors and member functions and all that to structs as well as classes.

casting the class over a function [don't know how it does it] so that the same function can be used by multiple classes

Errr.. huh?

Can you do that [typecasting] with a class? You probably could, I admit I don't really know a lot about c++. I would assume the class operates a lot differently in the background...

In C++, "struct foo" or "class foo" behave much as C's "typedef struct foo foo". The typedef keyword does still work, so "typedef struct foo *foop" works fine too.

I've explained above why I don't like using third party code libraries nor the STL.

Too big of an API? The 'S' part of STL really is true.

I seriously doubt I will ever embrace templates and namespaces, though; useful as they may be.

Templates are useful (and only really useful, AFAIK) if you need a bunch of functions that do the same thing to different datatypes. That's how the STL just has one "vector" class, rather than vecotr_of_int, vector_of_char, vector_of_void_pointer, vector_of_class_foo, etc. Namespaces are useful for libraries, then you don't have to worry if your implementation of printf() conflicts with the standard version of printf() or anything like that. In C, you'd call yours "byuu_printf" or something like that to get that assurance.

If you ever dabble around with RTOS/hobbyist OS development, a lot of them don't even have an STL implementation, so C++ code won't work.

Does one of the open source STLs not compile on those platforms?

A lot of OSes write all of their low-level kernel code in C only for this reason.

A lot of OSes write all of their low-level kernel code in C only because ASM is too much of a pain in the ass, and because in a kernel you pretty much have to have everything compiled in until it gets past initializing the HD and filesystem drivers...

[bztunk]

I seriously doubt I will ever embrace templates and namespaces, though; useful as they may be.

namespaces are *really* usefull and aren't difficult to use. When I use the ncurses library, I hate so much that #including <curses.h> pollutes the namespace with such common names as "update()" or "beep()".

If you ever dabble around with RTOS/hobbyist OS development, a lot of them don't even have an STL implementation, so C++ code won't work. Whereas C code does, since it's just a direct translation from c->x86, with no runtime environment/"whatever the hell the STL requires/does" required to run the code. A lot of OSes write all of their low-level kernel code in C only for this reason. This is irrelevant to my string library of course, just an example.

Hum... I don't know what you mean exactly by "runtime environment", but usually both C and C++ executables are linked to dynamic libraries. The C library provides usefull functions such as strcpy and qsort (the standard C library), while the C++ library provides the STL. You can link C code to a kernel library instead of the standard one, and you can do the same in C++. You *can* use language only features in C++, and actually, the STL was pretty late in C++ history.

[dakoda]

to hop back to sync for a moment, (sorry if this is already covered, and I'm way outdated), do we know for sure that the spc700 clock isn't simply obtained by dividing the master clock (~21mhz or whatever) by some integer? It's suspiciously close to /21 or /10.5, iirc (I did a lot of math trying to relate the clocks about 6 months ago and came to that). for the same reason too (emulate each chip per-cycle to see if anything amazing happens with timing problems). didn't get far enough to be conclusive before I had to leave though

[byuu]

It's obtained my dividing the APU clock by 24. I thought we already covered this (in this thread, no less)...
Nobody knows the correct speed of the APU clock so we're going with 24.576mhz for the time being.
I believe the concensus is that since we don't even know the correct speed of the APU, that getting 'close enough' will have to do.
anomie gave me some code that syncs the cpu<>apu using one fraction, so I'll probably go with that.

[Nightcrawler]

Why can't you just take an SNES and measure the speed of the main CPU and the APU and use those times in an emulator? It doesn't matter if the time varies between SNES's. You just need the times of one that works.

[whicker]

Why can't you just take an SNES and measure the speed of the main CPU and the APU and use those times in an emulator? It doesn't matter if the time varies between SNES's. You just need the times of one that works.

meh, read the first post of this topic...

[Nightcrawler]

What, just becuase it's hard to work with large numbers?

Then so be it. I'm not looking to get into a discussion or arguement about this.

[byuu]

No one knows the correct speed of the APU, we are going with 24.576mhz as a 'best guess'. Hence, the question was just how to sync two clocks. That way when we actually get the correct APU clock speed, we can just change the base clock speed for the APU and be done with it.

If everyone's tests have been correct and the APU really does run at different speeds on every SNES, then you're right: we don't need that timing to be perfect. It seems odd that Nintendo would choose to use a timing crystal that just ran at whatever the hell speed it felt like in a production console, however. We probably just aren't taking all details into account with our timing tests.

[Nightcrawler]

That's what I was getting at. Why can't someone with an oscilloscope
or logic analyzer measure the frequency of the APU? It seems like people who have done this do not get the same results? That would be an interesting case. Oscillators surely are not perfect, but they should run pretty darn close to one another in frequency, especially crystal based oscillators which I assume the SNES has.

Or is it because no one can measure the clock speed to a more accurate degree than 24.576Mhz? If this is the case, that should be close enough for correct operation. Most crystal oscillators I have seen in this Mhz range do not specify anymore accuracy than that. You'd get maybe one more decimal place at best.