"We Never Use Assembly Language"
in [ASM]
|
From: randyhyde@earthlink.net on 13 Mar 2006 14:03 Dragontamer wrote: > > If it was Randall's words, he would have said them. > > What you did was stuff his mouth with words that you said. Quite a > difference. > > Frankly; I don't remember when Randall said that HLA is a weak HLL. Typical quote from the "anti-HLA" crowd (RosAsmites, Annie, etc.). They take something out of context in order to infer something different. The statement "HLA is a weak HLL" comes from the more complete quote: "Of course HLA is a weak HLL, it's an assembler. All assemblers make weak HLLs." It's like Annie quoted that I said that "HLA.EXE isn't an assembler." (Which it is not, HLA.EXE is just a shell program that runs the actual HLAPARSE.EXE program that does the actual HLA compilation). The implication being that I claimed HLA is not an assembler (that is, a compiler for an assembly language). Wannabees quote is along the same lines. Amazing what a little context does for the story, eh? Cheers, Randy Hyde
From: randyhyde@earthlink.net on 13 Mar 2006 14:55 o//annabee wrote: > > > You can argue that 0000 000F is -1 all you want; but it isn't as > > practical as the standard > > 2s Complement version binary. > > I dont recall what two compliment even is. I have never needed this term > to write my stuff. And yet you constantly brag about how great an assembly language programmer you are (with a few comments about your stupidity, as a form of faux humility). As Rene would say, learn the basics of assembly language. And knowing about the two's complement numbering system is one of those basics you should learn about. If you don't have a quick reference, both AoA and Write Great Code Vol 1 discuss this topic in great detail. > > > As for Java: use an Array incorrectly because of an Off-by-one error, > > and you'd get > > an exception. > > So? Use an array incorrectly in RosAsm, you also get an exception. :) > Whats so nice about an exceptions ? :)) There is no guarantee you'll get an except in RosAsm (or any other assembly language, for that matter) in this situation. You really don't understand bounds checking, do you? Did you leave it turned off during all those years you were using Delphi? > > > Do the same in assembly, and you got a bug that can lead up to a > > catostrophic crash > > that could be *very* hard to find. > > True. Except they are ususally much easier to find with RosAsm, then it > was in Delphi! Probably because you never figured out how to turn on array bounds checking in Delphi. > While you fix those, you learn to avoid those. When the compiler handles > it for you, you never learn. Of course, you don't seemed to have learned how to tell the compiler to handle it for you. > I would really try to have you understand my > point of view. But I am afraid it will not help. The cost of having your > tool make up for your mistakes, in advance is high. Experience with lots of different programmers over the past four decades suggests otherwise. While there is a certain amount of truth to the fact that you will be forced to learn low-level things when working with a language such as assembly, the bottom line is having the compiler catch this sort of stuff for you greatly aides in the development process. > It will create > programmers alianated from real understanding of what they are doing. Yes, it can. But then, they often don't need to know the stuff as a result. And that's one of the reasons HLL programming is generally more productive. Now there is *no* question that knowing this stuff, even when using HLLs, is a good thing. But it's nice not to have to deal with all the details until the need to do so actually exists. And once you know the information, it's nice not to have to wallow in the details during normal development tasks. This information is nice to know during debugging, when a nasty bug arises, but you don't need to worry about it on each an every array access you make. If the compiler can handle the bounds checking for you, that one less detail you've got to keep track of manually. > How > are you going to advance the art of programming or the art of OS making, > if no programmer gets their hands dirty with the real thing? How are you going to advance the art of programming by reinventing the same thing over and over again? Better to let the compiler handle the mundane and intricate things rather than forceing the programmer to think at such a low level all the time. There is a time and a place for low-level code. But that time isn't always and that place isn't everywhere. And if you think it is, then I would ask you why you use RosAsm HLL-like macros in your code rather than writing all low-level assembly. > > You may sometimes wonder, why this issue is so important to me. And that > is part of the reason. Alianation. I have seen how much I really didnt > know, because I didnt use assembly. I now want to learn that, I want to > master it. And I found it to be harder to make such mistakes now. Good. Now you're prepared to go write some *real* code in a HLL like C/C++ or Delphi. Now that you understand what the compiler is doing do your code, you can write some pretty decent HLL code. And then you'll be able to appreciate how the compiler can handle mundane things like automatic bounds checking for you. And because of your assembly experience, you'll know when you can disable bounds checking and when it's not such a good idea to do so. > I _do_ > make them, and I even once made some bugs that will disable my OS. Its > horryfying, of course, I understand you position. But fact is that to me > the cost of letting the tool do all the work for me is too high. How would you know? You've never been in a position to write HLL code understanding the low-level details you claim to understand at this point in time. > The > resulting software is too slow. Really? Where's the proof of this? How much code have you written in both assembly and a HLL like Delphi, possessing the knowledge that you have today? > It has limitations that I am unable to > change. To me the price of using a HLL is much too high. Again, how can you say that without writing in a HLL with the knowledge you now possess. You remind me of a big goof I made when I was a freshman in college. I had done a lot of work in FORTRAN on an IBM 1130 system. Then I took a class on APL. I converted one of my FORTRAN programs to APL as a class project. The APL version ran a whole lot faster. For some time after than, I thought that APL was a faster language than FORTRAN. It didn't occur to me until much later that the APL interpreter was running on an IBM 360, which was a much faster machine than the 1130. You've got the same problem. You're comparing the assembly code you're writing today against the HLL code you wrote several years ago. Perhaps it hasn't occurred to you that your knowledge has extended a bit and that this same knowledge might help you write better code, regardless of the language. > And I am quite > sure that there are other mistakes to make in Java that will be just a > sucky to live with. Dont tell me serious Java programming is just > completly uncomplicated, because I have a hard time beliving you. Even I > do not know java. So how can you make any judgements about Java. This is so *you*. You know know a lot of languages (including other assembly languages) yet you talk as though you're an expert on productivity in all these programming languages. How can you possibly claim that RosAsm is the most productive programming environment when you really haven't used any others? > > But please, show me some Java app you created, so I can have a look. Which will tell you almost nothing, as you don't know Java. > I was pointing out to him that a possible bug in a undo feature is not > enough info to deem a whole (in my view) *wonderful* programming tool a > failure. You see, that the real reason for this fight. You, Sevagk and > Randall Hyde, are people who look for errors and then judge based on the > few errors. I can't speak for Dragon and Sevag, but I can tell you that I don't specifically look for errors. I write a benchmark to validate what Rene says about RosAsm speed, and the program crashes RosAsm. I pick a carefully written app with which to test the disassembler, one that I know doesn't contain code that will specifically trip up a disassembler, and it causes the RosAsm disassembler to fail. > I try more and more to learn from Betov to look for the > positive stuff, and not to judge the whole things in error because of some > small faults in a system. That's good that you're so forgiving. But to people who write software for a living, they cannot trust their livelihood to a programming tool that requires constant "work-arounds". The sad truth is, developers *do* judge the quality of the tool by its faults. But don't feel too bad. Most people don't refuse to use RosAsm because of a few small (or even major) bugs in the system. Most people refuse to use it because the design is not appropriate for modern software development. In particular, the lack of static linking is a non-starter for 99% of the people who look at RosAsm. > But actually, I am really, originally more like > SevagK. I too are used to lay weight on the negative stuff. The errors, > the non-perfections. But I more and more thinking that this is a desease, > and I am learning from RosAsm a new way of looking at things. To see, and > acknowledge the good stuff. And RosAsm has TONS of good stuff. It's good you are willing to work around the existing problems in RosAsm. But don't expect everyone else to be so charitable. Especially when there are stable tools that they can use instead. > Maybe. But it is also a bit funny to deem a tool in failure on a simple > bug in a small part of a system. RosAsm's failure isn't due to the plethora of small bugs in the system. Eventually, most of those could be fixed. The big problems with RosAsm are design flaws. Things like the inability to do static linking. The fact that the disassembler is not interactive like IDAPro. The fact that the editor doesn't follow CUA guidelines. Stuff like that. Until those issues are resolved, RosAsm's user base is going to remain quite small. > I agree. To some extent. I really do agree. But it takes a long time to > list all the features of RosAsm each time. Its just easier to say the size > of it. Anyway. Its written in assembly, and 3 megs of asm code, says a > hell of alot more than 3 megs of HLL code. Measuring in bytes is even more meaningless than lines of code. And, as software engineering has taught us, saying that you've written about n lines of assembly code pretty much says the same thing as saying that you've written n lines of HLL code, from a programmer productivity point of view. While I don't subscribe to the idea that it takes exactly the same effort to write one line of assembly has it does to write one line of HLL code, it is pretty obvious that the difference between the two is a relatively small constant fact (I doubt it's greater than two). Given that most HLL statements do more work than two assembly language statements, it's pretty clear that HLL programming is usually going to be more productive than assembly programming. The place where assembly wins is when efficiency considerations come into play and writing efficient HLL code turns out to be as much work (or more, if even possible) than writing the same code in assembly. > > But basically, yes, I do agree. > > > As for a true feat, Unix 6th Edition was done in less than 10,000 lines > > of code. > > Ok. Sounds impressive. Does that include the command lines utilities? Of course not. That's the kernel. > > > > TCL / TK beats RosAsm easily in terms of readability, simplicity, > > portability, and > > GUI programming in general. There are plenty of more productive tools > > than just > > assembly. > > Maybe. I never tried it. LIke so many other things you haven't tried. Yet you keep on bragging about how RosAsm is so much more productive than anything else. How can you make such claims when you've "never tried it."? > But we cant compare appleas and oranges. Wait! You're doing this all the time. You're comparing RosAsm against everything else. Definitely an apples and oranges comparison if I've ever seen one. > I am > talking about when you develop a GUI, from ground up. Why? Why should a person be forced to do this when existing language already provide GUI facilities? > When you design a > dynamic memory manager to drive it, when you build all the supportroutines > from ground up. But that's why languages like Java are so productive. You don't *have* to design memory managment from the ground up. > Can you do that in TCL? Have anybody tried it? Otherwise, > how can we have a comparison? Yes, we have a comparison. No work is required for memory management, it's already done for you. That's why TCL/TK programmers are more productive. They don't have to worry about this stuff. > > > As for HLA's speed; frankly, I don't care how slow C++ compilers are, > > easily a > > few magnitudes slower than HLA. I doubt anyone really cares about HLA's > > compile speed. > > I also doubt that anybody care. Least of all it author. But when using > RosAsm, one of its significant feature are the compiler speed. It makes > possible to test every simple change you make. Because it take lesser the > time it takes to have a zip of coffie, to see the app run. Earlier, you talked about how important it is that the tool not do stuff for you. That you learn from doing things the hard way. Well, the same applies to assembler speed. If you can reassemble the code so quickly, you start making changes to the code just to see what happens, without really *thinking* about the changes you're making. And as a result, you don't learn as much, you hack a lot more, and you wind up with a lot of extra code that really shouldn't be in the program (because you added it to see what happens and then failed to take it out when nothing bad occurred). The knife cuts both ways. > > > > And fails to disassemble Lemming-Ball Z startup runner, a 10930 byte > > file (11k) > > Do you understand why? I believe he does. The disassembler doesn't live up to its claims, in any case. Cheers, Randy Hyde
From: Betov on 13 Mar 2006 14:56 "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait news:1142277250.165087.319000(a)i40g2000cwc.googlegroups.com: > Actually, the HLA system consists of: > > HLA.EXE - a "shell" program that directs compilations and linkage > HLAPARSE.EXE, the compiler for the HLA assembly language > <some external assembler> This could be MASM, FASM, TASM, or Gas. > <some external linker> This could be Microsofts, TLINK, LD, POLINK, > etc. > <an external resource compiler> Generally Microsofts -- Win32 only > > Yep, three out of four of the programs are written by someone else, not > me? So what? The fact that FASM can use Microsoft's linker as an > external module doesn't change FASM's status, now does it? FASM is an Assembler. HLA is nothing, but one of the most absurd, ever seen, HLL Pre-Preparser. Period. Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 13 Mar 2006 14:57 Betov wrote: > > Same for me: I have _TONS_ of PEs that RosAsm fails to > Disassemble and to Re-Assemble in two click, and there > will always be. But, you know, in most cases, this kind > of clown does not even know where the interactive features > are, and, admitting they would know, they would, in all > situations, be utterly unable to understand where the > problem is, and how and what to do... Having looked at your documentation recently, I can understand why he wouldn't know where to look for the "interactive" features. :-) > > As, on the other hand, there is exactly zero competitor, > i fail to see any requirement of following up, with the > noises of such trolls. Well, I can't speak for the Dragonball project, but "99Bottles" disassembles just fine with IDAPro. RosAsm, nope. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 13 Mar 2006 19:14
Bertrand Augereau wrote: > > ??? The console market is *much* bigger than the x86 market, whether or > not it includes the Macs. > > > > > Now I don't claim that this means game companies *will* use assembly. > > There is still the issue that most programmers don't *want* to use > > assembly (for various valid reasons). But CPU portability is going to > > become a very weak argument over the next couple of years. > > Maybe for personal computing but not for gaming, that's for sure. Forgive me for not making that point clear. Then again, it sure looks like all the big game manufacturers are starting to line up behind the PPC. Still, you won't find anyone writing game software (console or PC) in assembly. Then again, the whole concept of "portability" and console machines is humorous. The hardware is so radically different on the machines that even if they had the same CPU, portability just doesn't happen without a tremendous amount of recoding. Wouldn't be a whole lot worse if they *did* write it in assembly. Cheers, Randy Hyde |