Prev: Reversing bit order in delphi ? (unmoderated)
Next: Linux / Windows GUI application with assembly
From: Betov on 20 Oct 2006 05:39 "KiLVaiDeN" <kilvaiden(a)gmail.com> ?crivait news:1161332769.186816.71070 @k70g2000cwa.googlegroups.com: > Look I don't have that much time to expand interminable posts on usenet > about my beliefs concerning HLA, and to quote your quotes of my quotes > which were quotes of your own words. Now, you know why he is a "Books Writer". :) Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 20 Oct 2006 10:41 Betov wrote: > "randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> écrivait > news:1161302686.606123.138670(a)h48g2000cwc.googlegroups.com: > > > If they decide to continue using the > > HLL-like statements in HLA, how is that any different than, say, people > > using Rene's macros for the HLL statements in RosAsm? > > Two points, here: > > 1) On the Assembler side, providing a Macros System > powerfull enough for assuming the needed HLLisms > is _WAY_ more work, than providing Pre-Parsers > doing the same task. Well, if you had a decent macro facility in RosAsm, this wouldn't be the case at all. Take a look at the implementation of the HLL-like statement via macros in HLA sometime. Fairly easy to do. *MUCH* easier than the code inside the HLA compiler. Of course, there are *many* advantages to handling the processing of these statements inside the compiler rather than via macro interpretation: 1) Processing the statements within the compiler is much faster than processing them via interpretive macros. 2) You can generate better code because the macros aren't aware of many other things going on during the compilation. 3) The result is more robust. You get better error messages when the programmer makes a syntactical (or other) mistake. > > [This was the reason why deffective Assemblers, like > MASM propose internal hidden Macros, making them > Compilers for Assembly Language, instead of real > Assemblers] You really don't know much about compiler design, do you? > > 2) On the Programmer side, the 1:1 correspondance is > preserved, as absolutely required, for diserving > the name of _Assembler_, and everything is kept > under the control of the Programmer, as long as > the Macros are _his_ Macros. Total BS. Once you use a macro, the mythical 1:1 correspondance is gone. Not that it ever existed on the x86 anyway (there is no 1:1 correspondance, even with pure machine instructions, because the instruction set encoding is ambiguous). I notice that you have finally implemented a weak conditional assembly facility in RosAsm. This means that a macro invocation, say ".if", can produce wildly different code expansions. Hardly 1:1. > > This is all of the difference in between an HLL and > Assembly: The 1:1 correspondance, and as soon it is > broken, we evidently are no more dong any Assembly. Therefore, when you write code the way you've written the RosAsm source code, you're not doing assembly. > > I did not invent the name "Macro Assembler", mind you, > clown. You didn't invent the name "assembler", either. But you seem to want everyone around here to think that you did. > > So, definitively, indeed, when one writes: > > If eax > 80 > Output CRLF > End_If > > ... with RosAsm, this is, for sure, real Assembly, No, it is not. It is an abstraction away from the machine code. If you want to call the above source code "real assembly", then the following is most certainly "real assembly" as well: if( eax > 80 ) then Output( CRLF); endif; Again, you make the mistake of confusing a language with the implementation of the language. The IF statements above are an example of a (non-assembly) language. Whether they are implemented via macros or internal to some compiler is irrelevant. The *LANGUAGE* is *not* pure assembly. Assembler, for better or worse, consists of machine instructions and data declaration statements. If you want to play the 1:1 game, then RosAsm doesn't come close, and certainly the RosAsm source code is not assembly language. > whereas, the exact same statement computed by a tool > designed for _hiding_ Assembly, can, much evidently, > have no relationship, at all, with any known form of > Assembly. Yes, > If eax > 80 > Output CRLF > End_If makes the assembly perfectly obvious, while if( eax > 80 ) then stdout.newln(); endif; completely obfuscates it. You're making perfect sense here. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 20 Oct 2006 11:04 KiLVaiDeN wrote: > > Look I don't have that much time to expand interminable posts on usenet > about my beliefs concerning HLA, and to quote your quotes of my quotes > which were quotes of your own words. Could have fooled me :-) > > Maybe I'm wrong after all in my opinion about HLA, I am always ready to > step back when i'm obviously mistaken, but it looks like you are never > ready to do such introspection about yourself on your own. Everytime > you talk to someone, you _MUST_ be right about _ANYTHING_. Nobody is > perfect dude. No, there are lots of areas where I don't have the experience or knowledge and I tend not to get involved in such discussions. But let me point out that I *have* studied programming language design, I *have* taught the subject (as well as compiler design and implementation) at the University of California and at Cal State University. So I *do* know a little bit about this subject. When someone, such as yourself, comes in speaking based on their emotions rather than on fact, you'll forgive me if I slap some wrists a little bit and offer a correction. Note that when it comes to things like the definition of a programming language, I actually *do* know what I'm talking about most of the time. > > I will just say, that I believe HLA is a nice piece of software, I > haven't denied that at any time. It's probably even good, accompagnied > with the book, to learn about the way the machine works, and eventually > about assembly. I have *read* it, but really fast, I haven't really > taken the time to do a detailed reading and testing, and I didn't read > the source code that much either, because I hate the line breaks > inserted between every single line of code, and couldn't bare them. I > couldn't clean it as well to have a more readable source code because > it was.. Not my favorite thing to do. If I interpret this correctly, you think that code is more readable if you cram a bunch of different statements together all on the same line, right? If that's the case, I would suggest that you're in a group that is a *very* small percentage of the population. Look at all the programming books out there. How often do you see the authors cramming multiple statements per line? The vast majority of people out there don't do that. As for inserting blank lines between statements, you might want to study graphic arts, typography, and document layout sometime. Many of the principles that make text easy to read apply to programs as well. My goal is to make the source code readable for the majority of programmers out there, not please someone who has convinced themselves that cramming lines together is more readable. > > I understand though your point of view : you say HLA is an assembler, An "assembler" is a compiler for an assembly language. HLA certainly fits that definition. Ergo, it is an assembler. Any attempt to otherwise eliminate HLA from the set of assemblers also winds up eliminating products like MASM or TASM, which are unquestionably assemblers in most people's minds. Every attempt around here, by Rene, yourself, and others, to exclude HLA as an assembler fails on this basic litmus test. And trying to claim that MASM is not an assembler (as Rene tries to do) is foolish. The majority of the assembly programmers in the world would refuse to accept such a definition. > because it has all the directives an assembler is supposed to provide, > in order to produce machine code, and therefore someone *could* use it > that way, as a pure assembler. Right. Okay. > > Yet I believe that *MOST* HLA users don't use HLA that way. They use it > with all the functions your library can provide. Absolutely nothing wrong with calling library code from an assembly program. RosAsm users, for example, do it all the time. If someone decides to call "kernel32.wsprintf" in RosAsm, does this mean that they're not writing assembly code? I find it amusing that you seem to think that RosAsm users calling code written in C (e.g., wsprintf) are writing "true assembly code" while HLA users calling code written in assembly language (the HLA stdlib) are not writing "true assembly". Perhaps you are under the mistaken impression that assembly programmers cannot call library routines? This is absolutely foolish. Assembly programmers have been doing this since before the days of the first assemblers (back when they worked in machine code). Claiming that HLA programmers are not working in assembly language because they call subroutines that are in the HLA stdlib (which, btw, is *not* a part of the HLA language) is a very weak argument. > > And there is my point : an HLA user, who is using MOSTLY the directives > of HLA, is NOT programming in assembly. He's programming in HLA. What is assembly? I could argue that someone who programs mostly in the syntax of FASM is not programming in assembly, s/he is programming in FASM. FASM is a language. Assembly is not a language. It is a generic term that encompasses several different languages. FASM is one of those languages. HLA is another. Yes, the programmer you mention is programming in HLA. They are also programming in assembly. Now you can argue that someone who programs using the HLL-like control statements in HLA is not really programming in assembly. And I would agree 100% with that. The same argument, however, applies to *anyone* who is using macros in their assembly source file. Have you looked at the RosAsm source code ever? Try and tell me that all those "IF" and "WHILE" macros are "assembly language". Given that Rene (and others) use those macros all over the place, if I were to believe your statement, I would have to say that Rene is not writing assembly code, he's writing ROSASM. > That's > what I'm trying to say from the beginning, but you twist my words all > the time. It's just as simple as that. Nothing to twist. You just haven't thought things through, that's all. > > You say I confused the language and the implementation of the language. Yes, you have. > Hmm who cares for the implementation ? The RosAsm crowd sure does. You seem to. After all, you're the one who pointed out that HLA generates source code for an underlying assembler. That's an implementation detail that is totally irrelevant with respect to the HLA language. > I'm talking about the language > fr
From: randyhyde@earthlink.net on 20 Oct 2006 11:05 Betov wrote: > > Yes, clown. The ones interrested can take a look at: > > < http://www.szmyggenpv.com/RosAsm.htm > Totally junk cut & paste code. > > ... which is the page of this "Wannabee". When seeing > the quantity, quatity and originality of this fellow's > productivity, everything is "proved", indeed. > > Just provide one single link, to one of your victims, > having produced one tenth of that, clown. Take a look at Sevag's stuff sometime. Cheers, Randy Hyde
From: Betov on 20 Oct 2006 11:08
"randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait news:1161355279.950758.166450(a)h48g2000cwc.googlegroups.com: > Of course, there are *many* advantages to handling the processing of > these statements inside the compiler rather than via macro > interpretation: > > 1) Processing the statements within the compiler is much faster than > processing them via interpretive macros. Probably the reason why RosAsm compiles huge Files in no time, when your thingie takes a coffea time on small ones... :) > 2) You can generate better code because the macros aren't aware of many > other things going on during the compilation. Last news from Randall Hyde: HLLs produce better Code than Assembly. Hey! Hutch--, --, --! Are you asleep? :) > 3) The result is more robust. You get better error messages when the > programmer makes a syntactical (or other) mistake. No doubt, clown. How is it, that your victims ask so much questions about how and why they fail on this and that? :) Betov. < http://rosasm.org > |