Assembly Language

by innovati on 06/23/2004 03:02, 26 messages, last message: 09/08/2006 20:39, 7465 views, last view: 05/19/2024 00:42

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   

#1: uhhh

by pushplay on 06/23/2004 03:26

Why would you extol the virtues of asm and then ask for a disassembler?

The problem with what your asking for is that there are several ways to do something in C that turns into the same exe (ignoring variable naming). And god help you once the optimizer gets at it.

Why do you ask?

reply to this message

#2: Um

by rtf on 06/23/2004 07:52

It's called a "compiler." You run your C or C++ through that and out comes machine code, which can be disassembled into assembly. The only reason why ASM is "faster" is because someone coded it by hand, so they were able to pull all the little optimizing tricks one can do when working directly with the hardware.

And this doesn't really relate to Cube.

reply to this message

#3: ...

by D.plomat on 06/23/2004 13:09

> I think there are translators that translate Assembly language into c/c++

I don't know of one. And i doubt it would produce human-readable C/C++ code.
The problem with language translators is that you obtain the least common denominator, ie you'd get a C code as readable as ASM :p

> a program that could take c/c++ and turn it into assembly

Same as rtf, that's a compiler. It does its own optimisations that are already pretty good for a majority of apps, but if you have two sources doing the same thing, one in asm and one in C, and the ASM one is way faster and tiny, translating the C one into ASM won't magically make it as fast and small as the original-ASM one... in fact it will produce *exactly* the same binary as if it hasn't been translated.

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

*ran* way faster... nowadays it's only useful if you're doing very little and massively repetitive loops for things like image or sound processing, or codecs, and you want to take advantage of some specific instructions sets. For 3D games, the basic and very repetitive operations are done by the graphic card... eventually some parts are coded in ASM but they're in the driver and you shouldn't bother if you want to code a 3D app.

Now the ASM is only used for OS programming (and often only the OS loaders), some drivers and codecs, but doesn't make a difference for applications.

reply to this message

#4: why?!?

by why wont it let me log in??? on 06/25/2004 17:25

I\'ll tell you why I want it, go to www.menuetos.org, and get the floppy image and boot up. You will be in an OS completely written by hand in assembly.

It has a full graphic desktop and everything. One of the features that I liked was a 3d maze game. It would run on my 500 mzh celeron with no 3d acceleration. And FAST!!!

Also, when parts of the Linux kernel were re-written in assembly, the whole kernel ran 10-40% faster.

Cube doesn\'t run on my computer, my Dad\'s yes.

If I could convert it into assembly it would run, so I wanted a program that could make it into assembly.

reply to this message

#5: ..

by krakensden on 06/25/2004 23:10

I don't think you're getting it. Assembly language is a _direct_ translation of machine code. So if you feel you can rewrite Cube in asm and make it better, just grab a hex editor and go for it. Everything you need is already there.
http://www.google.com/search?q=hex+editor&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8

reply to this message

#6: Re: why?!?

by rtf on 06/26/2004 04:42, refers to #4

Yes, if you want it in assembly for speed, no tool will do it for you.

YOU must rewrite it.

The examples you listed were hand-written code. And it's a pain to write, which is why we don't magically "translate" it all.

reply to this message

#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

   Board Index