Small size does not always mean assembler

Started by James C. Fuller, December 05, 2014, 03:56:49 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

James C. Fuller

Hutch posted an MASM example on the PowerBASIC forum that I think might get deleted?
I have a rebuttal and hope José does not mind me posting here.
  MASM is not the only answer to small apps.
This bc9Basic code: http://bc9.bcxbasic.com/cardfile2.htm
when translated and compiled with TinyC 32bit comes in at 11,264.
And for the Basic coder it is a bit more readable.

James
  •  

Brice Manuel

Given that TinyC still uses an assembler to produce its tiny code, I am not sure I get your argument when you are indeed using assembly to produce the tiny size in your example.  For assemblers, MASM is NOT the most optimized by today's standards, but as your test proves, assembly is the way to go if you want small size.  Now whether that assembly is hand coded or generated by a compiler is an entirely different argument, but both yours and Hutch's examples are using assembly to get the small sizes.

  •  

James C. Fuller

Brice,
  I think you may have missed the point. You do not have to write assembler source code to produce small executables .

James
  •  

Brice Manuel

#3
Quote from: James C. Fuller on December 06, 2014, 05:04:40 PM
Brice,
  I think you may have missed the point. You do not have to write assembler source code to produce small executables .

James

You are merely having your compiler write it for you.  My comments were strictly to your words "Small size does not always mean assembler" and pointing out if you want to refute that you shouldn't actually try and refute it by using assembly no matter how it is generated. ;c)  You proved that small size does always mean assembly.  And you proved that Hutch's handcoded assembly is extremely close to what is produced by one of the most optimized compilers out there.  Hats off to Hutch!
  •  

Steve Hutchesson

I was not exactly sure why James bothered when the original interface test was already smaller than his tinyC version but not to avoid me being a little sloppy and not picking the linker options with any great care, I bothered to set them properly and it reduced the size of the uncompressed EXE to 9216 bytes versus 11264 bytes from the TinyC version. To be a little blunt no C compiler is a competitor to MASM in 32 bit code and funny enough for the bare minimum window which in MASM is 1k, VC2003 can just do it in 1.5k.

Most know that size alone is not an important factor in modern software and one of the great advantages in writing assembler code is it is intrinsically so small that you can use different designs that take up extra space to get the speed up. Things like unrolled algorithms which C compilers do not do natively, the capacity to use large tables because of the minimum size of the code and of course them main advantage of writing assembler code, complete freedom of architecture.

I have attached the test file that James failed to get near with his C compiler.