Hi,
Juce looks like an interesting toolkit. I just downloaded the zip. Can:
a) the source be compiled with
b) alternatively, Juce applications be compiled and linked with the Juce library binary
Thanks
Vasudev Ram
Dancing Bison Enterprises
http://www.dancingbison.com
I’ve no idea, but it probably wouldn’t be difficult to get it working.
I remember watcom from the old days, but am surprised to see it mentioned - why are you choosing to use it when gcc and msvc are free?!
i have at least some reasons to justify research on watcom (used to program on it)
the most remarkable feature, the one i´m looking for years in other compilers is ASM integration.
the extra feature watcom has is that, it allows to inform on inline routines inside the cpp files what registers got corrupted.
by knowing this the compiler itself deals with preserving or not the necessary registers outside the inline code, wherever the inline code is put.
this results in very tight integrated asm code, that is also simpler, because there is no need to code pushes and pops to save any register, by just informing which registers were used.
also it avoids having those extra instructions turning the asm code smaller, and allows the compiler to optimize the block outside asm to avoid use of registers that will get corrupted inside the asm block, resulting in even more tight asm embedding.
when developing core aplications that need to use assembly mixed with c++ this is extremely handy. (i miss it a lot on other compilers, because choosing c for apps implies the need for speed, so good asm embedding should come included in the compiler as a necessary part of development)
watcom ide is ugly, but the compiler power definitely should not be underestimated, the openwatcom inherited code generation from the previous watcom c compiler that in the old days was very expensive and to justify it´s price used to generate the fastest compilation and the fastest code i´ve seen (at those old watcom days, it was much superior that m$ compiler)
i remember to this day when i was doing some brute force password breaking that started in borland pascal that when i ported the code to watcom using the asm embedding features, it became breathtaking fast (pascal was taking 2 hours to run the code and watcom did it in 5 minutes, and with further optimizations it turned to 30 seconds)
best regards
Interesting stuff!
here is the code i make to test asm integration (no pushes, no pops…)
#include <malloc.h>
unsigned i;
static unsigned long st1,st2,st3,st4,st0;
static unsigned long ad1,ad2,ad3,ad4;
unsigned lc1(unsigned,unsigned);
#pragma aux lc1=
"add eax,ad1 ",
"mov st1,eax ",
“db 0x0f,0xc8”,
"mov dl,ah ",
"add eax,ad2 ",
"mov st2,eax ",
“db 0x0f,0xc8”,
"mov dh,ah ",
“db 0x0f,0xca”,
"mov eax,st3 ",
"add eax,ad3 ",
"mov st3,eax ",
“db 0x0f,0xc8”,
"mov dh,ah ",
"mov eax,st4 ",
"add eax,ad4 ",
"mov st4,eax ",
“db 0x0f,0xc8”,
"mov dl,ah ",
parm caller [eax ebx] value [eax] modify [eax edx];
//right above it defines what goes in what goes out and what gets changed
void main(void)
{
i=addcalc1();
}
dated: 1995-05-07 gee!!! i´m probably an archiving freak!
this routine was made in a time that there was no support for the precious BSWAP 486 instruction (1 clock cycle!!!)
so i had to use DB´s for it
recently i´ve made some routines for dealing with the nasty getvarlen and putvarlen used for dealing with midi files (variable length delta time) and again the BSWAP instruction came very handy because there are thousand´s of calls for those convertions in those midi files.
also the files uses big endian notation for storing integers so using BSWAP to treat those speeds up the process.
there are some cases where for 2 byte integer is faster to use the ROL instruction to swap the bytes.
why are you choosing to use it when gcc and msvc are free?
i´ve just tested both and they failed in certain areas:
GCC
-not sure about the code generation but 100% sure about the compilation speed…
slower than death and umbearable (10 to 20 times slower than msvc6)
that surprises me because a compiler that was made to build several times the linux enormous packages should be built on speed compiling too, i can imagine the poor linux developers/users having to recompile the system all the time.
there are some techniques to supposedly “try” to speed up the mingw and one that got my attention is to install the ultimate++ app just to snatch the linker ld.exe and the archiver ar.exe to speed up gcc… just tried it… it doesnt work outside ultimate++.
the guys at ultimate++ obviously got ultra bored at mingw and made their own custom modules, but outside ultimate++ those generate lots of errors.
MSVC6
horribly patched installation but at least it doesn´t craaaaaaaaawwwwwllllll like the 2003 and 2005 versions. and they try to push the .net framework along just to make the developer even more dependent on their own complex way of doing a gui.
the first important point here is to get AWAY from MFC and get CLOSER to a different option like JUCE and by using m$ compilers, of course they want to push all this garbage along with the compiler.
after msvc6 they just tried to make a “cuter” environment at the cost of development speed and compiling.
and finally m$ never got the guts to add full support in msvc6 for giving a SINGLE package contaning the tools for developing aplications the version 6 so you have to do lots of patches that at the end create a lousy development environment. (processor pack, sdk, service packs…)
ridiculously enough, msvc6 does not upgrades the include *.h files to be at least compatible with win2000 so you have to do both the sp6 and the sdk.
worse than that when you install the sdk for at least give compatibility to win2000 (my os of choice, stable faster and acceptable size) it creates duplicated include file folder instead of correctly patching the include folder inside vs98 include folder.
they also recommend to put sdk include directory on top of msvc include and to keep both which is absurd because allows the compiler to recall vs98 headers when it doesn´t find sdk headers giving a lot of compilation headaches.
for the service packs the processor pack stoppet at sp5 so if you try to put sp6 it refuses to install and when dealing with core gui libs it is important to have good processor support to use fast instructions for screen management (mmx sse sse2)
due to those separate packs (sdk, sp5, sp6, processor pack) all the code that is found on the net compiles for some non standard combination of those.
in this matter mingw receives a 10+ note because they ignored all those “packs” and made their own updated winapi, so with a very small 40meg pack you get standard support that otherwise with msvc would require 1gig of packages to have the same functionality, if mingw was faster on compilation it would be absolutely perfect.
i´m tempted to use msvc6 because even with the monstrous amount of packages it compiles fast and i like to do small adjustments on the code and recompile a lot of times, but as soon mingw/gcc compiles faster than msvc i will switch to it and retire msvc forever.
there is one small but important detail that i´ve checked that msvc6 does that i know that borland doesn´t.
it allows inline asm procedures without stackframe.
those are functions that are full asm like:
inline alloc(int)
asm
{
//some code
}
when this gets called in the middle of the code it does´nt generate a call along with a push bp mov bp,sp and ret inside the function.
it adds the code directly inside main code (forbidden in borland)
this is risky but when properly used in functions that are called a lot it provides an imense speedup.
if you use this technique in a putpixel function for example it will fly.
And this core optimization in root functions affect all the other parent functions.
that´s exactly what watcom makes, insert asm code directly in the body of other code.
i remember to this day that when i used this technique to modify the putpixel in the graph svga unit in the old borland pascal days, it was speeded up by a factor of 8000%!!! (also doing some trick to avoid the MUL instruction using a lookup table) so all the other line, rectangle etc were benefited.
this is why i think watcom deserves a try because it may compensate those aspects of gcc and msvc.
if you try to use it, chances are that JUCE will run faster than gcc or msvc and the use of it for developers will be easier not having to install msvc complex packages or waiting for gcc to compile.
this may be a bit off-topic but i think it´s interesting to see more opinions on compilers beyond openwatcom.
just found some discussion here, today:
http://blog.gamecraft.org/2005/11/microsoft-visual-studio-2005
regards
