For a few days now, I have been pondering this(these) question(s) and I cannot put my finger on the answer(s).

Here are some of the questions I have:


  • Why are most assembly coded programs smaller in size than HL languages?


  • What do higher level languages have that make them produce bulky programs?


  • Is it all based on the coding style / technique?


  • And, finally, would it be possible to have a HLL with the size and speed of assembly?



Thanks for your time.

~ Steve ~

(Edit: Sorry if this belongs in another forum, I wasn't sure. )
Posted on 2005-04-30 16:30:45 by ~Steve~
No, it most definitely belongs here since it isn't a "specific issue", good looking out ;)

Now to answer your questions from my viewpoint.


  • Why are most assembly coded programs smaller in size than HL languages?



  • Assembly coded programs are smaller due to less overhead.


  • What do higher level languages have that make them produce bulky programs?



  • Compilers convert logic and data using generic/generalized algorithms. Compilers also do branch optimizations, which usually requires putting more code in for jump predictibility.


  • Is it all based on the coding style / technique?



  • To an extent, the most popular HLL is C/C++. When it comes down to it, C/C++ is nothing more than a higher logic extrapolation of basic CPU instructions. IF, FOR and WHILE are prime exmaples of things that get turned into Assembly language blocks with CMP, TEST, JMP, CALL and other common instructions. It is easier to see the logic in an IF statement since all the logic is there in spot "if (this=that)". In assembly, you have to understand the code block you are looking at to figure out the intention of the code, beyond comments. In the end, assembly naturally requires more commenting because it is less intuitive to humans than assembly language.


  • And, finally, would it be possible to have a HLL with the size and speed of assembly?



  • I will defer you to a generalization of NASA's generic quote adapted to amateur programming community. "Time, size, speed... pick any two ;)"
    Posted on 2005-04-30 16:55:34 by SpooK
    Hmm, I see.. But, would it not be possible to create an extremely complex compiler that will try to create the most efficient code possible?

    (I hope I put that correctly.)

    As much as I would like to accept NASA's quote... I can't :sad:
    Posted on 2005-04-30 17:19:09 by ~Steve~
    Code efficiency and size are not necessarily the same conceptual goal. Current compilers strive to make efficient code by using complex algorithmic based trees and patterns (i.e. Lex and Yacc). The idea of having a compiler making the "most efficient code possible" on current architecture is impossible in the context of human intervention. Humans know exactly what they want out of the code, compilers can only give a finite amount of results for a given set of instructions.

    Now to a realist's point of view, most compilers do a sufficent job. Going into the code and tweaking it to get a performance boost is specific to the task. For an Operating System project, I would say it is required... for a common Windows application, I would say it is a futile task.

    The last thing you need to understand is not how well compilers compile or assemblers assemble, but how well you can use and understand the language. Naturally, I can understand C code and PHP by looking at it because it is simple logic and data manipulation; but, I personally have taken the time to become well versed in assembly language and I can understand and write that equivalent code just as well as I can in C... it will just take a few more lines on occasion :)
    Posted on 2005-04-30 18:34:57 by SpooK
    Hi ~Steve~,

    Combining the power of asm and the efficiency of C ,  you can get smaller executables. The trick is to avoid the standard C run-time startup modules.

    Here are two versions of my tiny C startup modules, one for console applications, the other one for GUI apps.
    Both op the modules has the capacity of handling command line parameters.

    Reducing the size of C executables, these modules are designed to use with Visual C and Pelle's C compilers.

    Builded with these tiny modules, a simple application displaying a blank window is only 2 / 2.5 Kb
    Posted on 2005-05-01 03:53:26 by Vortex
    Wow, that's exactly what I was looking for, Vortex! Thank you, too, SpooK. I was just leaning more in that direction. :D


    avoid the standard C run-time startup modules


    Now I can utilize both to do some great things.

    Thanks!

    ~ Steve ~
    Posted on 2005-05-01 10:42:25 by ~Steve~
    Hi ~Steve~ ,

    You are welcome. Here are more two examples : one  for creating small C DLLs, the other one is a demo for creating an EXE of 1024 bytes, the minimum sized executable running on all 32-bit Windows versions.
    Posted on 2005-05-01 10:57:03 by Vortex
    http://www.ibsensoftware.com - get WCRT. Small overhead, good quality code - as with all Jibz' stuff.
    Posted on 2005-05-01 13:39:35 by f0dder

    But, would it not be possible to create an extremely complex compiler that will try to create the most efficient code possible?


    What's often said in compiler optimization books is -- you can never hope to create the most efficient code, you can only make better code.

    That said, you can sometimes create the most efficient code for only short self-contained segments of code. As soon as you add externally linked names, the compiler is hampered by lack of knowledge of external components. The important missing information is state changes (data, and external resources such as files), and when they happen or if they happen. To some extent, this can be eased by "whole program" optimization. Up till now, this has not been a common practice because most development systems were rather small systems by modern standards. It still is not a common practice because the linking function is a fundamental part of the process. Common linkers don't optimize, as that is considered a task of the compiler.

    If the self-contained code is complex enough, then decisions have to be made on splitting the use of cheap (or slow) and expensive (or fast) resources. Some of this tradeoff is affected by the code you write. But when the resulting target code is still too complex, the compiler might make choices that assembly language programmers won't make, affecting efficiency.
    Posted on 2005-05-01 14:29:52 by tenkey