i made a visit to Pelle's forum today
it looks remarkably similar to the masm32 forum :P
The two fora even have common taters ::)
Hi Dave,
Unfortunately, Pelles forum does not receive much input and feedback. Few coders are interested in Pelles project. :(
i don't know, Erol
it seems to be somewhat popular
the price is right, and the support is good and current
Hi Dave,
Pelle is a very good coder and he is maintaining regularly the compiler suite. Pelles forum should be much more active in my opinion. Only a small group of members is posting.
Quote from: Vortex on December 28, 2012, 06:00:32 AM
Pelles forum should be much more active in my opinion. Only a small group of members is posting.
Hmmm - the Open Watcom "forum" is a lot less active than PellesC ( although the OW C compiler is better in terms of reliability IMO ). I guess C is "not very sexy" anymore - still a bit more than Assembly, though.
Hi Japheth,
QuoteI guess C is "not very sexy" anymore - still a bit more than Assembly, though.
The reason is that they introduced extra layers like .NET Framework to "make easier" programming.
yah - c programmers seem to like vs and all their sharps and pluses (#, ++)
i was just looking at the Pelle's package command-line tools
nice stuff in there :t
with the recent upgrades, his assembler is becoming noteworthy, too
Quote from: japheth on December 28, 2012, 07:39:31 AM
Hmmm - the Open Watcom "forum" is a lot less active than PellesC ( although the OW C compiler is better in terms of reliability IMO ). I guess C is "not very sexy" anymore - still a bit more than Assembly, though.
Two particular things I like about OW:
1. It's open source and cross platform
2. It also supports C++ (still much work needed). If I'm not mistaken, their STL implementation is still incomplete.
BTW, where can I found recent binary built?
Their latest built is dated June 2010.
Quote from: japheth on December 28, 2012, 07:39:31 AM
I guess C is "not very sexy" anymore - still a bit more than Assembly, though.
I don't think so. In times where "Apps" for Smartphones and Tablets are "sexy", C should be too.
If I take a look at c-plusplus.de, I see that plain C is still "sexy" enough.
BTW, Pelles C is great ! :icon14:
Cheers
p.s. Oh, and happy new year to Australia !
Quote from: Greenhorn on January 01, 2013, 09:10:30 AM
p.s. Oh, and happy new year to Australia !
and everyone else, too :eusa_dance:
Quote from: dedndave on January 01, 2013, 11:12:06 AM
Quote from: Greenhorn on January 01, 2013, 09:10:30 AM
p.s. Oh, and happy new year to Australia !
and everyone else, too :eusa_dance:
Of course, buddy. The american continent should have arrived the new year by now too.
So, happy new year to earth. :biggrin:
yah - some time in march or april, i will get used to writing "2013" - lol
I used Pelles'C a couple of years ago for a short time,
and my impression was it is a great package. If I had to
write something in C I'd probably use it again.
Well we are in 2013 already, time is faster than me. :lol:
Happy new year folks.
Hi folks,
I took the liberty to post something on Pelle's Forum (http://forum.pellesc.de/index.php?topic=5098.msg19613#msg19613), in response to
Quotesome really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes
;)
Quote from: jj2007 on January 05, 2013, 06:37:07 AM
Hi folks,
I took the liberty to post something on Pelle's Forum (http://forum.pellesc.de/index.php?topic=5098.msg19613#msg19613), in response to
Quotesome really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes
;)
oh yes, the "really optimized compilers" will do our job. Really cool response, Jochen. :t
Gunther
Quote.NET Framework to "make easier" programming.
Yes many people coding now in RAD Studio XE (delphi) , .Net or QT
Last have i helped a friend about Win programming an he is a good coder (delphi)
but Win Programming not any experince ::)
Ok i know Big projects in Win programming wthout a Framework is not efficiency
I have last found a Cpp source from a good tool but this is written with a framework
No any apis oder anything :redface:
But i love it correct Craft :biggrin:
The general slowness of the MSVCRT functions can be partially explained by the need to run on older processors. For my test I used the Microsoft strcmp source from the PSDK, compiled with the range of optimizations provided with the VC++ Toolkit 2003 compiler.
Windows 2000 SP4, P6:
1105 cycles, crt_strcmp
882 cycles, strcmp_gb
883 cycles, strcmp_g3
882 cycles, strcmp_g4
882 cycles, strcmp_g5
882 cycles, strcmp_g6
1098 cycles, strcmp_g7
1098 cycles, strcmp_g7_sse2
1106 cycles, crt_strcmp
883 cycles, strcmp_gb
883 cycles, strcmp_g3
883 cycles, strcmp_g4
883 cycles, strcmp_g5
883 cycles, strcmp_g6
1098 cycles, strcmp_g7
1098 cycles, strcmp_g7_sse2
1106 cycles, crt_strcmp
884 cycles, strcmp_gb
883 cycles, strcmp_g3
883 cycles, strcmp_g4
883 cycles, strcmp_g5
883 cycles, strcmp_g6
1097 cycles, strcmp_g7
1097 cycles, strcmp_g7_sse2
Windows XP SP3, P4 Northwood:
633 cycles, crt_strcmp
1318 cycles, strcmp_gb
1316 cycles, strcmp_g3
1316 cycles, strcmp_g4
1316 cycles, strcmp_g5
1319 cycles, strcmp_g6
893 cycles, strcmp_g7
911 cycles, strcmp_g7_sse2
619 cycles, crt_strcmp
1317 cycles, strcmp_gb
1316 cycles, strcmp_g3
1316 cycles, strcmp_g4
1316 cycles, strcmp_g5
1316 cycles, strcmp_g6
904 cycles, strcmp_g7
914 cycles, strcmp_g7_sse2
626 cycles, crt_strcmp
1317 cycles, strcmp_gb
1315 cycles, strcmp_g3
1316 cycles, strcmp_g4
1316 cycles, strcmp_g5
1316 cycles, strcmp_g6
904 cycles, strcmp_g7
915 cycles, strcmp_g7_sse2
Note how much lower the cycle count is for the XP SP3 MSVCRT, and that this is running on a processor with a lower IPC than the P3.
The relevant parts of the code-generation options:
/G3 optimize for 80386
/G4 optimize for 80486
/G5 optimize for Pentium
/G6 optimize for PPro, P-II, P-III
/G7 optimize for Pentium 4 or Athlon
/GB optimize for blended model (default)
/arch:<SSE|SSE2> minimum CPU architecture requirements, one of:
SSE - enable use of instructions available with SSE enabled CPUs
SSE2 - enable use of instructions available with SSE2 enabled CPUs
The SSE2 option had no effect.
XP SP3, Pentium IV 3.2 Ghz :
1341 cycles, strcmp_g3
1341 cycles, strcmp_g4
1342 cycles, strcmp_g5
1342 cycles, strcmp_g6
922 cycles, strcmp_g7
922 cycles, strcmp_g7_sse2
701 cycles, crt_strcmp
1341 cycles, strcmp_gb
1340 cycles, strcmp_g3
1341 cycles, strcmp_g4
1341 cycles, strcmp_g5
1341 cycles, strcmp_g6
921 cycles, strcmp_g7
923 cycles, strcmp_g7_sse2
701 cycles, crt_strcmp
1341 cycles, strcmp_gb
1340 cycles, strcmp_g3
1341 cycles, strcmp_g4
1341 cycles, strcmp_g5
1341 cycles, strcmp_g6
921 cycles, strcmp_g7
921 cycles, strcmp_g7_sse2
Press any key to continue ...
Quote from: MichaelW on January 05, 2013, 07:37:01 PM
The general slowness of the MSVCRT functions can be partially explained...
...
The SSE2 option had no effect.
That is an understatement ;-)
Innermost loop of strcmp_g7_sse2
004059D6 ³> Ú84C9 Útest cl, cl
004059D8 ³.³74 14 ³jz short 004059EE
004059DA ³. ³8A4E 01 ³mov cl, [esi+1]
004059DD ³. ³0FB642 01 ³movzx eax, byte ptr [edx+1]
004059E1 ³. ³83C6 01 ³add esi, 1
004059E4 ³. ³83C2 01 ³add edx, 1
004059E7 ³. ³0FB6F9 ³movzx edi, cl
004059EA ³. ³2BC7 ³sub eax, edi
004059EC ³.À74 E8 Àjz short 004059D6Intel(R) Celeron(R) M CPU 420 @ 1.60GHz (SSE3)
616 cycles, crt_strcmp
886 cycles, strcmp_gb
885 cycles, strcmp_g3
886 cycles, strcmp_g4
885 cycles, strcmp_g5
886 cycles, strcmp_g6
889 cycles, strcmp_g7
890 cycles, strcmp_g7_sse2
119 cycles, StringsDiffer
616 cycles, crt_strcmp
886 cycles, strcmp_gb
886 cycles, strcmp_g3
885 cycles, strcmp_g4
886 cycles, strcmp_g5
885 cycles, strcmp_g6
889 cycles, strcmp_g7
888 cycles, strcmp_g7_sse2
120 cycles, StringsDiffer
616 cycles, crt_strcmp
885 cycles, strcmp_gb
886 cycles, strcmp_g3
888 cycles, strcmp_g4
888 cycles, strcmp_g5
887 cycles, strcmp_g6
888 cycles, strcmp_g7
889 cycles, strcmp_g7_sse2
119 cycles, StringsDifferIntel(R) Core(TM) i5-2450M CPU @ 2.50GHz (SSE3, SSSE3, SSE4.1, SSE4.2, AVX)
430 cycles, crt_strcmp
474 cycles, strcmp_gb
471 cycles, strcmp_g3
474 cycles, strcmp_g4
470 cycles, strcmp_g5
477 cycles, strcmp_g6
475 cycles, strcmp_g7
470 cycles, strcmp_g7_sse2
64 cycles, StringsDiffer
430 cycles, crt_strcmp
471 cycles, strcmp_gb
473 cycles, strcmp_g3
471 cycles, strcmp_g4
473 cycles, strcmp_g5
470 cycles, strcmp_g6
470 cycles, strcmp_g7
471 cycles, strcmp_g7_sse2
65 cycles, StringsDiffer
430 cycles, crt_strcmp
472 cycles, strcmp_gb
471 cycles, strcmp_g3
472 cycles, strcmp_g4
471 cycles, strcmp_g5
474 cycles, strcmp_g6
470 cycles, strcmp_g7
469 cycles, strcmp_g7_sse2
64 cycles, StringsDiffer
My test results:
strings 1+2 are not equal
strings 1+1 are equal
strings 1+2 are not equal
strings 1+1 are equal
Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (SSE3, SSSE3, SSE4.1, SSE4.2, AVX)
Press any key to continue ...
421 cycles, crt_strcmp
406 cycles, strcmp_gb
408 cycles, strcmp_g3
406 cycles, strcmp_g4
410 cycles, strcmp_g5
406 cycles, strcmp_g6
408 cycles, strcmp_g7
407 cycles, strcmp_g7_sse2
49 cycles, StringsDiffer
376 cycles, crt_strcmp
407 cycles, strcmp_gb
407 cycles, strcmp_g3
408 cycles, strcmp_g4
406 cycles, strcmp_g5
407 cycles, strcmp_g6
407 cycles, strcmp_g7
408 cycles, strcmp_g7_sse2
49 cycles, StringsDiffer
376 cycles, crt_strcmp
406 cycles, strcmp_gb
407 cycles, strcmp_g3
408 cycles, strcmp_g4
407 cycles, strcmp_g5
406 cycles, strcmp_g6
407 cycles, strcmp_g7
408 cycles, strcmp_g7_sse2
49 cycles, StringsDiffer
Gunther
Hi Gunther,
You should try the /*8 compiler switch :biggrin:
Hi Jochen,
Quote from: jj2007 on January 06, 2013, 04:17:16 AM
You should try the /*8 compiler switch :biggrin:
evil to him who evil thinks.
Gunther
AMD Athlon(tm) Dual Core Processor 4450B (SSE3)
451 cycles, crt_strcmp
674 cycles, strcmp_gb
676 cycles, strcmp_g3
677 cycles, strcmp_g4
675 cycles, strcmp_g5
674 cycles, strcmp_g6
675 cycles, strcmp_g7
675 cycles, strcmp_g7_sse2
140 cycles, StringsDiffer
I have always found some humour in compiler/assembler comparisons and I have seen it from both directions yet even a cursory grasp of both shows they are very different animals. In particular Pelle's toolset collection does enough clever things to be a viable part of an experienced programmer's toolkit. Pelle has always kept his tools very up to date in terms of specification but as is the case with most programming languages, some of the baggage associated with them could be best described as very ordinary.
I have seen my share of assembler code that was absolute chyte just as I have seen my share of C code that was not worth the disk space it occupied yet with either written by an "artist" who actually understands the language in real detail, you get very good results with either if you write them well. The two languages have very different strengths, true C is portable and it is part of the language design where assembler is highly configurable on a specific platform at the expense of portability.
The solution to making a language popular is for there to be enough good quality code available and to make it accessible to folks who want to write in that language form. It can be watered down, compromised and made look like trash if its badly done (the one that always made me laugh was VBX files for C programming long ago, the worst of VB technology repackaged for people who could not write decent C code in the first place.
If enough people wrote enough decent C code that was properly interoperable with assembler code without the overhead of C runtime libraries it would be useful to both assembler programmers and C programmers.
I keep in mind a particular Sedgewick hybrid sort that truly defied any meaningful optimisation to get it faster. A particularly good algo that was a premium performer in C and even very complex optimisation would not make an assembler version faster.
Every tool has its place, the trick is to know its place and how to use it to get optimum results.
Quote from: hutch-- on January 11, 2013, 05:10:54 PM
If enough people wrote enough decent C code that was properly interoperable with assembler code without the overhead of C runtime libraries it would be useful to both assembler programmers and C programmers. ... Every tool has its place, the trick is to know its place and how to use it to get optimum results.
Amen to that. :t That's exactly the point.
Gunther
Hi folks,
I am bit stuck with polib, maybe somebody has a bright idea:
- I need GSL for windows (Download the latest windows GSL binary 32 bits (http://wiki.rglab.org/index.php?title=Public:Installation_of_GSL_from_Windows_binary))
- I'd like to convert \Masm32\PellesC\GSL\bin\libgsl-0.dll to a static library, \Masm32\PellesC\GSL\lib\libgsl-0.lib
- polib /MACHINE:X86 /NOUND /out:../GSL/lib/libgsl-0.lib ../GSL/bin/libgsl-0.dll creates that library
- but PellesC complains it can't find anything inside there...
- PeView reveals that the members are all decorated, like _imp_gsl_matrix_alloc, _imp_matrix_set etc
- so I hoped /NOUND would help, but it doesn't. No complaints but they are still there.
PellesC compiles it but then I get
POLINK: error: Unresolved external symbol '_gsl_matrix_alloc'.
POLINK: error: Unresolved external symbol '_gsl_matrix_set'.
I am sure it's an absolute noob error, but I am stuck. Any idea?
http://vortex.masmcode.com/ (http://vortex.masmcode.com/)
use Erol's dll2inc, then Erol's def2lib
dll2inc libgsl-0.dll
notice that libgsl-0 has dependencies in libgslcblas-0
they both need to be present
def2lib libgsl-0.def
it might work :P
the one i created is about 1 gb
notice Erol's little cinvoke.inc also
Quote from: dedndave on January 19, 2013, 05:21:05 AM
the one i created is about 1 gb
You want to scare me :eusa_naughty:
The lib is 1 MB, and it works - thanks :t
lol
oops - i read the size wrong :biggrin:
Erol is da man
Quote from: jj2007 on January 19, 2013, 04:08:05 AM
- PeView reveals that the members are all decorated, like _imp_gsl_matrix_alloc, _imp_matrix_set etc
Which indicates that it's an import library. GSL is not available as a static library?
it is, now, thanks to Erol :biggrin:
Quote from: dedndave on January 19, 2013, 06:19:05 AM
it is, now, thanks to Erol :biggrin:
No, it's an import library, as MichaelW did tell already.
And even that creation of an import library wasn't needed, because the package already contains both static libs ( "libsl.a" ) and import libs ( "libsl.dll.a" ), AFAICS.
Quote from: japheth on January 19, 2013, 06:32:53 AMthe package already contains both static libs ( "libsl.a" ) and import libs ( "libsl.dll.a" ).
It does indeed contain these files. How can they be used in PellesC? Sorry if these are stupid questions, but until now my lib files all ended with .lib ;-)
The source compiles fine with the newly created *.lib files but it asks for the presence of the DLLs. And the exe crashes in various places. It's not my source, I just have the honorable task to port it from a Unix machine to Windows...
Quote from: jj2007 on January 19, 2013, 06:41:25 AM
It does indeed contain these files. How can they be used in PellesC? Sorry if these are stupid questions, but until now my lib files all ended with .lib ;-)
In the MS world, libraries end with .lib, and in *nix they start with lib* and end with .a.
They both are COFF ARchives, buth sometimes with subtle differences, that make this and that tool crash if feeded with something from the "wrong" world.
The import files should be usable in any case, but static libs may require a certain static CRT - and I don't know ( and seriously doubt ) whether PellesC is the best option here.
Quote
The source compiles fine with the newly created *.lib files but it asks for the presence of the DLLs. And the exe crashes in various places. It's not my source, I just have the honorable task to port it from a Unix machine to Windows...
Good luck!
Hi Jochen,
I'd like to convert \Masm32\PellesC\GSL\bin\libgsl-0.dll to a static library, \Masm32\PellesC\GSL\lib\libgsl-0.lib
Sorry if I misunderstand : you would to create a static library from a DLL?
I downloaded the package, installed it, copied libgsl.a to the directory of my previous cygwin/gsl test, and changed the relevant includelib statement in my test code to:
includelib libgsl.a
And assembled and linked the test app, and the only problem I can see is at the end of pass1:
libgsl.a(infnan.o) : error LNK2001: unresolved external symbol ___fpclassify
test.exe : fatal error LNK1120: 1 unresolved externals
Details in the attachment.
Quote from: Vortex on January 19, 2013, 07:16:18 AM
Hi Jochen,
I'd like to convert \Masm32\PellesC\GSL\bin\libgsl-0.dll to a static library, \Masm32\PellesC\GSL\lib\libgsl-0.lib
Sorry if I misunderstand : you would to create a static library from a DLL?
Hi Erol,
Well, yes and no: The dll to lib version compiles at least, using your tools, the "use .a directly" version suggested by Japheth and Michael fails with Unresolved external symbol '__imp___iob' - there are half a Million Google hits for this particular iob error message, so I am in good company :biggrin:
GSL in MasmBasic (http://www.webalice.it/jj2006/MasmBasicQuickReference.htm#Mb1112) works perfectly, but higher forces [i.e. colleagues who are not proficient in assembler] oblige me to use C. The usual mess :(
Hi Jochen,
msvcrt.dll exports a function named _iob :
\masm32\bin\dumpbin /EXPORTS C:\WINDOWS\system32\msvcrt.dll | find "iob"
113 6F 0000F207 __iob_func
136 86 0000F207 __p__iob
320 13F 0004FC80 _iob
type \masm32\lib\msvcrt.lib | find "iob"
___p__iob
__imp____p__iob
__imp___iob
__iob
___p__iob
__imp____p__iob
__imp___iob
__iob
__p__iob
__imp____p__iob
_iob
__iob
__imp___iob
Quote from: Vortex on January 19, 2013, 08:29:06 AM
Hi Jochen,
msvcrt.dll exports a function named _iob :
Yes, adding \masm32\lib\msvcrt.lib to linker commandline helps :t
It boosts the exe from 80k to well over 1MB, too ;-)
When I got back to the static lib test it occurred to me to add a dummy procedure to my assembly module:
__fpclassify proc C
ret
__fpclassify endp
And the build then succeeded and the EXE ran apparently normally. Since the DLL I tested previously worked OK, the problem would appear to be with that particular build of the library.
IIRC the iob components are for file streams, and are normally managed entirely by the CRT.
And in the DOS days, and IIRC, the Microsoft linker treated the libraries differently depending on where you included them on the Link command line, specifically, in the library section or in the object module section. Although I can't recall which is which ATM, one location caused Link to include everything, and the other caused it to include only what was referenced.
i don't remember ever trying a library as a module on the old linker
but, i used them as libraries, and only what was referenced was linked
Thanks to everybody for your help :icon14:
Here is the source of a test trying to get a random value - it fails with an exception:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <gsl_randist.h>
#include <gsl_cdf.h>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_matrix.h>
#include <gsl/gsl_rng.h>
//#include <gsl\gsl_linalg.h> //JJ
int main(int argc, char *argv[]) {
const gsl_rng_type * Ra;
gsl_rng * r;
gsl_rng_env_setup();
Ra = gsl_rng_default;
__asm int 3;
r = gsl_rng_alloc (Ra); //FAILS - debugging shows it should be a POINTER to gsl_rng_default
}I tried Ra = * gsl_rng_default and variants but that throws errors. The version above compiles fine but crashed inevitably in gsl_rng_alloc...
I wonder if I misread the documentation of gsl_rng_alloc here (http://www.gnu.org/software/gsl/manual/gsl-ref.html#Random-number-generator-initialization)...
Quote18.3 Random number generator initialization
— Function: gsl_rng * gsl_rng_alloc (const gsl_rng_type * T)
This function returns a pointer to a newly-created instance of a random number generator of type T. For example, the following code creates an instance of the Tausworthe generator,
gsl_rng * r = gsl_rng_alloc (gsl_rng_taus);
Attached the PellesC project, with lib files constructed with the Vortex tools. Two missing dlls are available here (http://gnuwin32.sourceforge.net/packages/gsl.htm) - scroll down to Download,
binaries.
EDIT: Hier stand Misst
I don't currently have Pelle's C set up, so I used the Microsoft VC++ Toolkit 2003 compiler. I used the static library from the GSL installation, without renaming it. The only anomaly I encountered was several warnings:
/out:test.exe
libgsl.a
test.obj
libgsl.a(default.o) : warning LNK4217: locally defined symbol __iob imported in
function _gsl_rng_env_setup
libgsl.a(error.o) : warning LNK4049: locally defined symbol __iob imported
libgsl.a(stream.o) : warning LNK4049: locally defined symbol __iob imported
Thanks, Michael. So this one doesn't run into an exception. Interesting. Will look into it asap :t
If I use the static libraries libgslcblas.a and libgsl.a (from the package) with PellesC, it work as expected.
Thanks a lot, qWord & Michael & Japheth. I got the small test file working with original .a libraries :t
Right now I am struggling with the Unix "_iob" thing (http://research.microsoft.com/en-us/um/redmond/projects/invisible/src/crt/iob.c.htm)
The simple source compiled fine with the Masm32 msvcrt.lib, and stopped crashing once I replaced fprintf(stderr, "Whatever\n"); with printf ("Whatever\n"); ::)
The more complex source (which I cannot post) now complained about malloc multiply defined... so I had to remove \Masm32\lib\msvcrt.lib from the linker's commandline, which made 'the Unix "_iob" thing' reappear. So I decided to revert to Erol's tools, and to create a tiny msvcrt.lib that contains only (msvcrt.def)
LIBRARY msvcrt
EXPORTS
"__iob_func"
"__p__iob"
"_iob"
Guess what? It works :t