Index
> Heap > The Compiler Returns! (Vs The mummy returns)Goto page 1, 2, 3 Next |
| Author |
|
|
kohlrak
Quote: [15:31] shash^clp: asm isn't easier After that he ignored me. I found that funny. After that, i deleted the connection information. I won't waste my precious time on fools like him who have no honor enough to fight on even ground. Under what grounds can anyone say that you can set rules to compare C to ASM, aside from if it can run or not. In all respects, he beat me in coding, but as he ignored to take the argument further and fight on even ground, he lost the argument between C and ASM. Which, needless to say, is a pointless argument anyway, since a chain is as only strong as it's weakest link. What i don't understand is how some one that appaers to have that much experience will stick up for HLLs saying they're better in all respects. I still beat him in size in RAM, but he wouldn't listen to that. Oh well... I guess this goes into the archive of HLL obcession. HLL obcessors fail to realize that ASM does have some advantages, yes it *can* take longer to code certain things, but the question then comes to become which is better between longer coding or longer running and/or downloading. Just some food for thought. What i found interesting was he actually took longer to code (as my code took about 15 seconds to type and hit compile while his took a few minutes). Out of curiosity, what are the thoughts of you all on this matter? |
|||
03 Jun 2007, 21:02 |
|
|
vid
size is not important.
and even if, kohlrak could have used same packer/whatever on his exe and it would be even smaller. and kohlrak was right about size alignment, it wasn't valid PE (even though loadder accepted it) |
|||
|
03 Jun 2007, 22:32 |
|
|
Goplat
If you're willing to mangle the PE headers as much as slash^clp's compressor undoubtedly does, 558 bytes is actually pretty large. This guy made a Win32 program only 97 bytes long.
|
|||
|
04 Jun 2007, 01:49 |
|
|
kohlrak
Indeed. Such a file is some what alarming considering that it's supposedly capable of downloading a DLL as well. The most alarming part is that nothing caught it as suspicious, which makes me wonder how AVs figure out weather or not something is a virus, because i've seen non-virus programs marked as viruses already.
Though this "webdav" thing seems interesting. I thought you'd have to use winsocks to accomplish something like this in windows. Edit: More alarming than that is the fact that the program got passed my firewall. Firewall didn't even ask if it should have gotten internet permissions... Edit2: I just realized something else. When loading it had an unusual behavior co-existant with that other guy's program. It loads with a little amount of space needed, then it jumps up to a huge amount of space then does it's task. I wonder if that comes from the webdav thing or if it comes from the pe loader trying to realign it. If it's the webdav thing then i doubt he was using C, and in which case i would have beat his assembly code. I'm going ot hex edit this exe of his. EDIT3: "lz32.dll"... Welp, so much for that unless some one here knows the lz compression. I've noticed "HASH" was used alot... |
|||
|
04 Jun 2007, 03:16 |
|
|
m
Code:
Asm Vs HLL
1) Asm is Smaller Size.
"Hello World" type programs are smaller for sure.
But try writing the MS-Word eg. and the difference
in size will seem insignificant at best.
Also, without any tweaking etc. a bare bone window
generated by a C program and another by a Asm program
use almost equal amounts of RAM each.
2) Asm is Faster.
Why tweak to the microcode level when optimizing the
Algorithm itself is far more resoundsing option.
3) Asm Gives Control.
With modern OSs everytime you try to do something
stupid with Asm you get a "Seg Violation" at best.
4) Asm is Art.
Sure !
5) Asm is addictive.
Yeah !
6) Asm is very well designed programming tool.
Agree !
7) Asm is never Obsolete.
That's Right !
8) You become well aware of your PC with Asm.
Absolutely !
9) Asm is best done with fasm.
At present, yes !
And it will remain so, as long as Tomasz Grysztar lives.
A) There's nothing that Asm can't do.
Tautology.
B) We Asm lovers just love it, for no reasons,
OR for whatever reasons.
C) Asm is, what it is, there's no need to compare it against every
new programming tool.
After all no one does Asm because because eg. C is bad.
We do it because we like it, and not that we do it because
we dislike something else.
|
|||
|
04 Jun 2007, 06:02 |
|
|
DustWolf
m wrote:
1) Have you tried? Per my experience, the statement is just trying to proove a point using a myth. 2) That's the whole point of ASM. You don't use it because you optimize in it, you use it because you can write the code directly, without having to avoid the limitations the language is imposing on you. 3) Try debugging in C and in ASM and tell me if not being able to read your own code in a debugger direcly is a great plus and if errors in C code are any more obvious than the ones in ASM (not to mention most of the errors one can easily make in C, would only appear in ASM code after 3 days of no sleep and no coffee). |
|||
|
04 Jun 2007, 10:44 |
|
|
DustWolf
Taking into account the point that any experienced programmer would have to know what the code he writes is doing, which is only possible by translating it into ASM in your mind as you write it. Thus not programming in a HLL does not make the process of programing more complex, but actually simplifies it.
The most commonly used point is that commercial applications cannot afford the devolopment time needed for writing software in Assembly. I had a real life commercial task in front of me... Being a great fan of certain HLLs I of course tried to make it work in one of those. After 3 months of unsucessfully trying to track down and eliminate all the misterious bugs (I tracked the last one down to a windows component I had no control over), I took a simple week of programming and rewrote it's entire functionality into a DLL written in FASM, debugging and optimization included; it's worst bug being a windows resource leak in an optimized if clause (which was summarily done away with with some overhead resource freeing). The integration of the DLL into the remaining HLL code was a fair amount easier than the OCX I previously opted for and a number of resources-related troubles the code had beforehand (high in mathematical calculation, thus resource intensive) were also eliminated due to the high efficiency of the code. Explaining why I opted to redo the thing in Assembly to my boss took some tactful diplomacy, but after he seen it work the way it does he didn't mind the choice of language anymore. There are so many myths floating around these topics, it makes me wonder how many of those great program devoloping minds actually have a clue about what they're usually talking about. I've seen people take textbook examples of optimizations that were supposed to be done by compilers and according to their findings, the compilers don't actually do them, that's one myth there. I've seen some wonderfully compiled Delphi code (3 times "SHL eax,1" in a row). I've had first hand experience on what can happen if you rely on the claims of compiler-makers that their usage simplifies programming and debugging (it's a what-the-label-says kinda thing... if you do it exactly how they wanted it, it works, if you want to make something new or useful, it fails catastophically). I know HLLs can be used to make some simple straightforward things. Making something in ASM that could be done in a shellscript is pointless. But making things on which you are responsible for ensuring their functionality, there is hardly any other responsible choice but ASM, unless the solution is already offered from another reliable source. Please note that most software companies do not hold themselves responsible for the functionality of their code. |
|||
|
04 Jun 2007, 11:08 |
|
|
vid
Well, i cannot agree with you guys.
In most cases, using HLL is more practical for few reasons: - It provides portability over processor architectures - It is more readable for others, only few programmers can read assembly "fluently" - It provides developing "framework" you must build yourself in assembly (not really true for C language) - HLL constructs are sometimes better than goto-only in pure assembly (not as often as many think, but still) I have done two bigger assembly projects: (Becher Shock game and FASMLIB), and I also did bigger C project in work, so i think i have enough experiences to judge from both sides. Problem with HLL is that you should only use it if you understand how it works (not only WHAT it does, but also HOW). When you understand this, then HLL construct may be a nice helper, which allows to do most common constructs simpler. Just like FASM's "import" or "proc" macros, do you use them? But when HLL is used by people without good ASM backing, it gets raped to terrible measures. They want to use HLL constructs without understanding them, and result is same as using FASM macros without understanding them: mess. Even worse is that programming is being pushed in direction to make using HLL without understanding it even easier, and that results in beasts like .net framework, or some smart code wizards. I can't say this is entirely bad, if some company needs to build boring huge system and doesn't care about performace, it's better for them to hire .net programmers whose training is cheaper. Nothing against. But quality suffers... |
|||
|
04 Jun 2007, 11:58 |
|
|
DustWolf
Don't mean to pick and troll but I got a question here, vid.
vid wrote: - It is more readable for others, only few programmers can read assembly "fluently" Are you sure this is a problem? I have found commented HLL code to be much harder to make out typically than commented ASM code. You don't read the code, you read the comments and make out the parts you need to link or modify. I've been mostly interfacting different programming languages (of different levels of high-levelness) and found a lot of problems with figuring out how to properly interface some C code and such because you never really know if something is data, pointer or symbol-terminated string and what innitialization you need to do before calling a function. |
|||
|
04 Jun 2007, 17:09 |
|
|
vid
Quote: Are you sure this is a problem? I have found commented HLL code to be much harder to make out typically than commented ASM code. You don't read the code, you read the comments and make out the parts you need to link or modify. how much experience with larger C projects do you have? I had same problem, but now i found out that i can read C code quite well. anyway, many programmers don't know assembly at all, and many know it only very sparsely and couldn't understand asm code, that was what i meant with this sentence. For me reading C or Asm code is equally hard - Asm code needs more time to understand actual code, and C code needs more time to learn all abstraction created by coder 
Quote: I've been mostly interfacting different programming languages (of different levels of high-levelness) and found a lot of problems with figuring out how to properly interface some C code and such because you never really know if something is data, pointer or symbol-terminated string and what innitialization you need to do before calling a function. |
|||
|
04 Jun 2007, 17:18 |
|
|
rugxulo
Face it, when the whole HLL vs. asm wars start up (as they frequently do), it's usually C vs. asm. Now, we know that C is very popular, portable, widely accessible via libs and APIs, and is quite fast (one of the fastest) with decent optimizations due to a relatively long lifetime for a programming language. However, lots of so-called "improvements" have been invented since, and it's debatable whether any of them have any significant merit in some common cases.
As Dustwolf said, using a shell script is often much better than reinventing the wheel on everything. But, C itself is not all powerful like assembly. And I certainly think that C is nowhere near as "easy" as some people claim. It is widely used in various dialects (same with assembly), so both have the same steep learning curve. This guy (in the above chat transcript) is not worth arguing with. If it's easier for him to do C, let him. Different people have different skills and needs. But assembly is not bad unless your OS is a pain to program with it. You're basically limited by your own knowledge, OS, and development tools and program needs, not by any specific language itself. |
|||
|
04 Jun 2007, 23:37 |
|
|
kohlrak
Quote: 3) Try debugging in C and in ASM and tell me if not being able to read your own code in a debugger direcly is a great plus and if errors in C code are any more obvious than the ones in ASM (not to mention most of the errors one can easily make in C, would only appear in ASM code after 3 days of no sleep and no coffee). But here's the problem. I've run into so many errors in my C++ code that were only fixable with "patches." For example, i called cin >> (), got my junk, but then i wanted to call cin.getline(), which i had to do twice, because i had to patch it for the first one. I find this irresponsible way of getting your code to work, and things like this were my main reson for going to assembly. Quote: Explaining why I opted to redo the thing in Assembly to my boss took some tactful diplomacy, but after he seen it work the way it does he didn't mind the choice of language anymore. Exactly, and that underlined line is amount the truest things i've heard all day. Anyone can make the same kind of apps with the same kind of buttons and everything, but if you wanted to use a new algroitham, you're in deep doodoo. Quote: I know HLLs can be used to make some simple straightforward things. Making something in ASM that could be done in a shellscript is pointless. But making things on which you are responsible for ensuring their functionality, there is hardly any other responsible choice but ASM, unless the solution is already offered from another reliable source. Please note that most software companies do not hold themselves responsible for the functionality of their code. And for good reson. Quote: It provides portability over processor architectures Processor, but not platform. Exit the standard library, which you pretty much need to do to get away from console, and you're risking cross platform-ability. Quote: It is more readable for others, only few programmers can read assembly "fluently" I prefer CMPs and Jxxs over { }. I can't count how many times i have messed up on brackets. Quote: Problem with HLL is that you should only use it if you understand how it works (not only WHAT it does, but also HOW). When you understand this, then HLL construct may be a nice helper, which allows to do most common constructs simpler. Just like FASM's "import" or "proc" macros, do you use them? Usually, we can understand the language itself, but how the functions affect the things in the code is anyone's guess. Quote: But when HLL is used by people without good ASM backing, it gets raped to terrible measures. They want to use HLL constructs without understanding them, and result is same as using FASM macros without understanding them: mess. Even worse is that programming is being pushed in direction to make using HLL without understanding it even easier, and that results in beasts like .net framework, or some smart code wizards. Leads to inability to pass the code onto others unless you use the exact same version of the exact same program. The further you go with wizards, the less your projects will port. I've noticed some of this happening in visual studio and sometimes even in fasm without the assistance of wizards. It's common, and then you have the issue of tutorials in C/C++ and other HLLs that don't use examples that require wizards, and well the results sometimes work and sometimes dosn't. DirectX comes to mind in this. Quote: I can't say this is entirely bad, if some company needs to build boring huge system and doesn't care about performace, it's better for them to hire .net programmers whose training is cheaper. Nothing against. But quality suffers... Sounds like microsoft. They own the computer platforms these day, pretty much, so they have no worries. No one challenges them, so you have the BS with vista and stuff. Quote: Asm code needs more time to understand actual code, and C code needs more time to learn all abstraction created by coder Then when i code, you'll deffinately want to read my ASM code, because my C++ code is... Cryptic to say the least. Got some really bad grades for it. |
|||
|
05 Jun 2007, 00:32 |
|
|
vid
kohlrak wrote: For example, i called cin >> (), got my junk, but then i wanted to call cin.getline(), which i had to do twice, because i had to patch it for the first one. I find this irresponsible way of getting your code to work, and things like this were my main reson for going to assembly. could you explain what exactly overloaded operator >> does with cin? This is exactly what i was saying, about using things you understand. Quote: Processor, but not platform. Exit the standard library, which you pretty much need to do to get away from console, and you're risking cross platform-ability. actually, even the cross platform portability is little bit better, because there are numerous portability libraries, most without interface for ASM. Quote:
yeah, but C for example "jcc" too: "if (cc) goto somewhere". You don't have to use brackets (but you have to have procedures, yeah, sometimes it's annoying) Quote:
not them, i meant "bussiness" companies with lot managers, buzzwords, solutions, boxes&arrows, graphs, etc... |
|||
|
05 Jun 2007, 05:57 |
|
|
DustWolf
vid wrote:
Since I work with very HLL languages, I often have to turn to other languages to create the components I need to do stuff (not that what I do is such a biggie, but there is a performance problem as the programs need all the CPU a box can spare). By interfacing I thus mean linking modules written in other languages to the trunk of the code written in a HLL. Needless to say, nearly all HLL languages including C present problems with interfacing with a different programming language, primarily because they are only made for interfacing with themselves (the point of which evades me; see above what I said about compilers and labels). |
|||
|
05 Jun 2007, 09:33 |
|
|
vid
DustWolf: yes, this is quite big problem. Microsoft was fighting it with it's COM technologies, but finally gave it up and created .net
|
|||
|
05 Jun 2007, 12:00 |
|
|
DustWolf
vid wrote: DustWolf: yes, this is quite big problem. Microsoft was fighting it with it's COM technologies, but finally gave it up and created .net The point being that documented FASM DLLs work just fine! It wouldn't be a problem if they didn't make it a problem. |
|||
|
05 Jun 2007, 13:06 |
|
|
kohlrak
Quote: could you explain what exactly overloaded operator >> does with cin? This is exactly what i was saying, about using things you understand. Yea, but what they didn't tell me was that it left a "trailing newline" when i used it. Quote: actually, even the cross platform portability is little bit better, because there are numerous portability libraries, most without interface for ASM. But from what i've seen, alot of programs still use the kernel. Quote: yeah, but C for example "jcc" too: "if (cc) goto somewhere". You don't have to use brackets (but you have to have procedures, yeah, sometimes it's annoying) Goto's are no longer taught from what i've seen. In the few situations that they are, they are shuned upon. The biggest problem that i've seen is the lack of understanding, which i'm sure you've seen. The thing is that now adays, HLLs are considered the best way, and theachers often encourage the lack of understanding, because there's "no need, for it does everything for you." But irregardless, gotos don't neccesarily improve readability over CMPs much... Quote: not them, i meant "bussiness" companies with lot managers, buzzwords, solutions, boxes&arrows, graphs, etc... Most of the time you can find free software out there to do that for you. Quote: Needless to say, nearly all HLL languages including C present problems with interfacing with a different programming language, primarily because they are only made for interfacing with themselves (the point of which evades me; see above what I said about compilers and labels). Monopoly. If they aren't compatable, everyone has to switch to that, which could provide new jobs (on the upside), but on the downside is that companies can take advantage of this to take over a particular programming language (we can see this now with microsoft's new call to flash) forcing people, in the end, to use only their products. Quote: DustWolf: yes, this is quite big problem. Microsoft was fighting it with it's COM technologies, but finally gave it up and created .net As i said above, it's more than just .net. Quote: The point being that documented FASM DLLs work just fine! It wouldn't be a problem if they didn't make it a problem. Not for us, but it would be for them. |
|||
|
05 Jun 2007, 23:34 |
|
|
vid
kohlrak wrote:
acutally, i would name it that it "doesn't skip following blank characters". I faced similar design problem with FASMLIB, and their solution is really the best one, we can discuss it in separate topic if you like. Quote:
like? (besides assembly demos, yeah, these do it) Problem with using linux kernel API is that it is not quaranteed by any means. It is just something over what can be standard C library built. Idea is something like this: if the kernel API needs to change, libc is only app that needs to change too, and all other programs using libc are fine, nothing is broken. Quote: Goto's are no longer taught from what i've seen. In the few situations that they are, they are shuned upon. The biggest problem that i've seen is the lack of understanding, which i'm sure you've seen. The thing is that now adays, HLLs are considered the best way, and theachers often encourage the lack of understanding, because there's "no need, for it does everything for you." But irregardless, gotos don't neccesarily improve readability over CMPs much... agree Quote: Most of the time you can find free software out there to do that for you. |
|||
|
06 Jun 2007, 00:08 |
|
|
rugxulo
Anybody who thinks goto is frowned upon in "real life" needs to read this thread (mainly to see my examples).
Also, HLLs do not do everything, they usually rely on libraries which themselves cannot be written entirely in such language. Am I the only one who balks every time C is called "low level"?? It's nowhere near as low level as assembly. There are things you just can't do in C (standard, especially). |
|||
|
07 Jun 2007, 04:38 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|