Voxlap
Voxlap copied to clipboard
Ericson2314
NOASM preprocesser conditions done poorly
So my stupid way of doing things was
#ifdef NOASM
// C
#else
#ifdef __GNUC__
// gcc inline assembly
#else
#ifdef _MSC_VER
// msvc inline assembly
#endif
#endif
This is bad because it only works if the compiler is either GCC or MSVC and the architecture is x86.
In kplib.cpp JonoF did something like
#if defined(__GNUC__) && defined(X86-64) && !defined(NOASM)
// gcc inline assembly
#elif defined(_MSC_VER) && defined(X86-64) && !defined(NOASM)
// msvc inline assembly
#else
// C
#10
JonoF's way is obviously far superior because NOASM is the default so in unanticipated setups (e.g. ARM + open Watcom) the program will still compile.
I'm undecided on which is better, seperate files, and using directory structure to organise, or IFDEFS. The advantage of the latter is that it's more likely you'll see bugs when the 3 bits of code are next to each other.
Alternatively, it might be possible to hack together macro sytem to do Both. GCC can be done
"
statmenent;
statmenent;
"
(also, IRC?)
I've already started on this using the improved ifdef structure. There is also the USEV5ASM define, which is similar, so we'll have to be careful to only use USEV5ASM for includes and NOASM for code blocks with optional assembly code.
Hey Lensman, I saw you started working on but did
#if defined(NOASM)
// C
#if defined(__GNUC__) && !defined(NOASM)
// gcc inline assembly
#elif defined(_MSC_VER) && !defined(NOASM)
// msvc inline assembly
#endif
This isn't as good, because the compiler should fall back on the C code on processors where the assembly isn't supported EVEN if it isn't defined. I know see we really want:
#if defined(__GNUC__) && defined(X86-64) && !defined(NOASM)
// gcc inline assembly
#elif defined(_MSC_VER) && defined(X86-64) && !defined(NOASM)
// msvc inline assembly
#else
// C
#10
I'll edit my original post to update
Also if you could rebase, not merge, off my lensman-conservative branch that would be excellent, I'll start merging that stuff into conservative and rebasing the other branches too.
No worries, I'll make those changes. Is the NOASM flag staying around for good so we can still have a pure C version in future?
Yeah, I imagine eventually there will be a both PURE_C flag, and GCC_SIMD flag so we can replicate assembly algoriths in http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html , but for now NO_ASM is good.
Those vector extensions look handy. Most of the time I use GLM which is pretty solid, but I like the idea of builtins.
It's a library which mimics the matrix and vector functions of OpenGL, check it out if you do any GL work it is a real boon.
OK, see https://github.com/Ericson2314/Voxlap/commit/d467829d05294545ebb4cc088440421b57c7f38f for exactly what I want (this was done by combining a few if your commits and some manual tweaks). You were all the way there except for the defined(__i386__) part. :)
Also, don't forget to rebase off my branch called lensman-conservative. This will allow you to keep up to date easier as I basically rebase your stuff for you with that branch.
Ah, good stuff. Just to clarify, when you say rebase do you mean git merge base? I've started from a fresh copy from Ken's site, and I'm refactoring it, so I always have a 100% working copy. When this is in synch with the current conservative branch I will save that as the refactored-original branch, and then start folding in all the gcc changes and save it as refactored-conservative. I'm doing this by folding in one change at a time and testing against a working program. Doing it this way has already highlighted some bugs, in the assembly code, so I'm hoping it will highlight some others. I've also started replacing some of the smaller assembly functions in voxlap5.c with their intrin / __builtin equivalents where applicable. The bugs I found were in v5.masm, but now I can compile v5.masm, and v5.nasm with VS2010 Express, and they both work.
Excellent!! Yeah please push your restart branch as soon as possible, I'd love to help! I also recommend you clean up extra white-space every commit, as it helps maintain clean revisions. Of course the initial re-factor touches a hell of a lot of stuff, but yeah it sounds like you are being clean as hell after that.
Ah, that explains it. git, rebase is a whole separate thing. https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html it's sort of shunned upon as a SVN-esque thing, but it does have it's uses.
Ah found your repo. Yeah I recommend you actually do this as a new branch and not a new repository starting from my "initial commit". Then you can cherry-pick and rebase between the original port and the redo with less difficulty.
@lensman Sorry to here that your HDD is in trouble, and thanks for pushing what you have. If you don't mind though I think this is a good example of why it's better to commit and push a lot. Even if things are not quite the way you want for that clean history, I am more than happy to go back and rebase them. Additional, there is no need for a last-minute rush commit when you probably are trying to use the hard drive as little as possible.
I think we both like having clean git histories, but with git rebase and friends you don't need to worry so much about getting it right the first time. :)