Jump to content

Recommended Posts

Posted

Does compilers make the same program bigger o shorter in size?

 

 

Because in ASM a program that weight 66byte (.com) i had its source code and compiled it with TASM and got an 876bytes program (.exe) why is this happening?

Posted

dunno the exact reason, but i used to code in Pascal, C, C++ and VB, and after the code was debugged, linked and executed, the final .exe file was indeed larger, much larger then the source file.

 

but then again, this is why you should restrict the syntax to what you need. meaning if you need to have a value between 1 and 50,000(and only whole numbers) for example, use int as opposed to double int or any of the higher ranges. an obvious reason is if using more or less a shotgun to kill a fly, and especially if the code is lengthy, the time to debug, link and compile the code would be tremendous.

Posted

(this programs is different from the first i talked about but occurs just the same)

i compiled it in tasm

 

 

.model tiny

.386

.code

org 100h

_main:

 

push 0a000h

pop es

 

mov ax,13h

int 10h

 

xor di,di

mainlop:

stosb

add al,0a0h

jnc mainlop

add di,320

jnc mainlop

 

quit:

int 16h

 

mov ax,03h

int 10h

 

ret

 

end _main

 

Someone compiled it and got 255bytes.

 

I did it and got 884bytes.

Posted

did you use the exact same code? or did you change the vars around?

 

{edit}

 

because if it's the exact same code, then when compiled, it should not deviate that much. regardless of the pc you're on.

Posted

Yes, its the same code.

Thats why i am thinking the compiler is the reason.

 

(btw in asm there are no types)

(and what you could car var is mostly a label)

Posted
Because in ASM a program that weight 66byte (.com) i had its source code and compiled it with TASM and got an 876bytes program (.exe) why is this happening?

 

Probably because it has to link it with a static library.

  • 2 weeks later...
Guest malcolmX
Posted

Indeed, different Assemblers (compilers for assembly language) must link

standard function libraries provided by the assmebler vendors. That

impacts not on the interim object files .O/.OBJ but on the resulting .EXE file

because as you know there are many ways to implement functions so the

resulting sizes differ.

 

.COM files are very small fooprint executables (code and data all

in 64K if i remember correctly) that work under MS-DOS. .COM use

internal BIOS calls (int 10h and int 21h) implemented in the computers

BIOS not by the assembler vendors.

 

And indeed, assembler does have types BYTE, WORD, LONG, DWORD, etc..

what admiral said about the types you use is very important.

 

Also COMPILER OPTIONS that are set make a difference.

Different assemblers use different defaults, e.g. INCLUDE DEBUG INFO ON/OFF, NEAR and FAR memory access ON/OFF, STATIC and DYNAMIC linking ON/OFF, also options that you set if u want to let C/C=+ and other languages

access you code or just other assembler applications. These settings affect the final size.

 

To be honest, its not really worth it worrying about this unless ofcourse

you have a specific need to write very tight code. And even if that is the case, optimise your code first. Then run it through various compilers to get the best result. Assembler is assembler. So by running the same code to yield different results on different compilers, you should realise that it is the

compiler making the difference and not your code.

 

But having said that, there are pre-directives (like .386, .model tiny etc.)

you can use to make ur code behave more uniformly across platforms.

 

Nice to meet another coder in Mexico. Are there any brazilians here??

 

I used to use Intel 386 assembler in 1995 so its been a while...

What kind of stuff are you working on??

 

Malcolm

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.