Assembly Language

by innovati on 06/23/2004 03:02, 26 messages, last message: 09/08/2006 20:39, 7447 views, last view: 05/04/2024 12:51

We all know that programs written in assebly run WAY FASTER, and are a lot smaller. I think there are translators that translate Assembly language into c/c++, does anybody know about a program that could take c/c++ and turn it into assembly?

This help would be greatly apreciated.

Thanx, Innovati

   Board Index   

#7: Re: why?!?

by spentron-postcrash2 on 06/26/2004 05:31, refers to #6

I think there's some confusion, either between the days when compilers weren't as good and CPUs were weak and now, or between compiled languages and interpreted ones, the latter of which is very slow indeed.

reply to this message

#8: Re: why?!?

by e:n:i:g:m:a on 06/26/2004 06:39, refers to #7

Well Even if Assembly is FASTER than C++ (Which I am not denying that it is), C++ is STILL very fast and efficient... I dunno why we are even arguing this...

reply to this message

#9: ..

by sinsky on 06/27/2004 11:59

I downloaded menuet and tried it, liked the 3D screensaver and the games, but wasn't able to really test the speed issue which was my intention. You see, this thing runs on my new Pentium 4, but doesn't support my old 486. It's not a graphics card problem, it just enters the mode I choose and hangs before displaying the background, icons, etc. - I can move my mouse but nothing else. The 3D maze is simpler than Wolf 3D, but looks much worse and I seriously doubt it runs faster.

Nice games, though, and very small size.

reply to this message

#10: Re: ..

by Aardappel on 06/27/2004 17:56, refers to #9

cube is compiled for pentium code (maybe even pentium pro/II code, can't remember). It's not going to run on a 486, unless there is one that runs at 300mhz that is. Even the fastest 486 that exists cube would be unplayable.

reply to this message

#11: Re: ..

by sinsky on 06/28/2004 11:57, refers to #10

Actually, people have been porting 486 and older stuff to modern PCs instead the reverse, and quite successfully I think. On Windows platforms sound seems to be the main problem, and a sound emulator does all the job for most 486 games. For the rest I use Dosbox (http://sourceforge.net/projects/dosbox), it works for many games and programs like Fasttracker 2 on XP for example. I managed to run FT2 only with low sound quality, but probably there's a way to make it run smoothly.

(I don't want to go totally off topic again, so for those of you who don't know I'll mention that part of the cube music is in Fasttracker .xm format.. if you can run it, you can make music for cube games in this format and I think it uses less CPU resources than OGG)

reply to this message

#12: compile

by hungerburg on 06/29/2004 13:06

gcc -S source.c gives you the text fed to the assembler in source.s; also try gcc -O3 -S source.c for optimized assembly. now start making modifications ;> though I imagine this being more of a use to see how well the compiler does...

reply to this message

#13: Re: compile

by D.plomat on 07/02/2004 14:51, refers to #12

I think that wouldn't make a noticeable speed difference, as for modern games, the two things impacting speed are:
-engine design: changing language won't change it unless totally rewritten with different design, as an engine that uses the same algorythms and structures as Cube would still be the Cube engine, whatever language it is written into... the only thing afecting speed would be using different algorythms and/or structures but then it wouldn't be Cube engine but another engine.

-ASM micro optimisations: those are for very thight and massively repetitive loops in the drivers themselves, and probably most of them aren't x86 assembly but some kind of instructions understood only by the radeon/geforce chip. So changing those would mean writing a new OpenGL driver.

If we consider C as an intermediary translation from design to machine code, this translation is near 100% efficiency, nowadays this isn't noticeable for all really-compiled languages, as spentron said the only cases where they suffer a speed penalty is when they do the translation on the fly, like interpreted languages, and even in this case those languages are used for high-level stuff and the micro-optimisations belongs to the OS, libraries and drivers, so when writing a game/end-user app the coder's duty to performance is only in -the engine design and -the libraries choice (which IMO are already optimal in Cube)

reply to this message

#14: ..

by dd_2 on 09/07/2006 17:36

Real programmers code in binary.

reply to this message

#15: ..

by chead on 09/07/2006 23:49

"does anybody know about a program that could take c/c++ and turn it into assembly?"

I needed a laugh, thanks.

"Real programmers code in binary."

You're lost, too. :P

reply to this message

#16: Re: ..

by shadow,516 on 09/08/2006 00:07, refers to #15

\"Real programmers code in binary.\"

I do believe (or at least hope) that he\'s being sarcastic on that one.

P.S: note to self 9+3 does NOT equal 11...

reply to this message

#17: ..

by makkE on 09/08/2006 00:15

Guess it refers to this one:

http://weblog.cemper.com/a/Real-programmers-code-in-binary.php

reply to this message

#18: Re: ..

by hampus_ on 09/08/2006 00:39, refers to #17

haha :)

reply to this message

#19: ..

by pushplay on 09/08/2006 01:52

>> We all know that programs written in assebly run WAY FASTER, and are a lot smaller.

no

>> does anybody know about a program that could take c/c++ and turn it into assembly?


I swear to god I laughed for a minute straight.

reply to this message

#20: Assembler...

by Osbios on 09/08/2006 14:37

There is a reason why you use Assembler for nothing more then SMALL Parts of time critical Programs.

e.g.:

Pascal
mem[$A0000 + X + Y*320] := Color

Assembler (16bit) with some \"optimisation\"
mov bx, [Y]
shl bx, 6
add bx, [Y]
shl bx, 2
add bx, [X]
push 0xA000
pop es
mov al, [Color]
mov [es:bx], al

Perhaps this isnt 100% correct, but it shows how much unreadable code you get.

Try to search a bug in Code like this! :D

reply to this message

#21: Re: Assembler...

by eihrul on 09/08/2006 17:24, refers to #20

To be constrasted with in modern times:
sall $2, %eax
sall $6, %edx
movb $0xA0000(%eax, %edx), $Color

The Intel world has moved on from 16 bit, dude. :P

reply to this message

#22: Re: Assembler...

by eihrul on 09/08/2006 17:28, refers to #21

Oy, I already made bugs in my 3 lines of code. I give up.

reply to this message

#23: Re: Assembler...

by eihrul on 09/08/2006 17:36, refers to #21

movl %eax, ecx
sall $6, %eax
sall $8, %ecx
addl %ecx, %eax
movb 0xA0000(%eax, %edx), $Color

There. I feel better now.

reply to this message

#24: Re: Assembler...

by eihrul on 09/08/2006 17:41, refers to #23

Damn, just realized:

sall $6, %eax
leal (%eax, 2, %eax), %eax
movb 0xA0000(%eax, edx), $Color

This is why I let compilers write the shit for me! Otherwise I'd spend all my time optimizing 3-5 lines of code. Sauerbraten is, oh, only 20,000 some lines of code now, which would be about 50,000-100,000 lines of assembly.

reply to this message

#25: ..

by makkE on 09/08/2006 17:52

Me knowing nothing bout coding would say: that looks a shitload more complicated than c++ ...

reply to this message

#26: Intel world?

by Osbios on 09/08/2006 20:39

@eihrul: The "Intel world" already use 64Bit! And why not use Intel Syntax in a "Intel world"?

reply to this message

   Board Index