"We Never Use Assembly Language"
in [ASM]
|
From: randyhyde@earthlink.net on 14 Mar 2006 10:54 Betov wrote: > "sevagK" <kahlinor(a)yahoo.com> écrivait news:1142301695.148972.226240 > @j52g2000cwj.googlegroups.com: > > > Rosasm has weak macros > > If RosAsm has a weak Macros Sysytem, Troll, show us the port > of the RosAsm Proc Macros set to a couple of other Assemblers. > > Thanks in advance for the god laugh time. Search the Google archives. I did this for you a long time ago. But you keep bringing this up, hoping people have forgotten. While you're at it, look up the posts where I demonstrated how to convert *every* RosAsm macro feature to MASM. That's sufficient proof that *anything* that can be done with RosAsm can be done with MASM. Of course, the converse is *not* true at all (that is, MASM can do lots of stuff that RosAsm cannot). As for Proc/Endp, why would any MASM user bother? They've already got those built into the language. And they work *much* better than your pathetic RosAsm macros. It's like that time you tried to write a macro to simulate the stdout.put macro in HLA -- you wrote something that kind of *looked* like stdout.put for some *very* special cases, but in no way did everything that stdout.put does. The same is true for your PROC/ENDP macros. Not even close, and certainly no cigar. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 14 Mar 2006 10:59 Betov wrote: > "sevagK" <kahlinor(a)yahoo.com> écrivait news:1142301695.148972.226240 > @j52g2000cwj.googlegroups.com: > > > But "if" and ".if" are macros that do the same thing, but > > 2 are needed because Rosasm can't figure out which form you need on > > it's own. And then there is "..if" and it gets wackier from there. > > The RosAsm Macros System is _WAY_ powerful enough, for > assuming identical "If / End_If", at all level of nestings. False. It cannot handle arbitrary nesting. MASM, TASM, and HLA can. (And I believe that NASM and FASM can, as well). You can argue all you want about how people don't need IF/ENDIF nested to arbitrary levels, that, perhaps, 10 levels ought to be enough, but the bottom line is that these other assemblers can do things your's cannot. And although you *might* not need this feature for IFs, it is important for other things. > These form of Macros _DO_ exist, by the way. And still you push the *horrible* versions of these macros onto your users. So instead of fixing the problem, you keep carrying around the old baggage version after version. Oh well, at least you can claim that all the old programs still compile version after version in RosAsm :-) > > And the fact that you fail to understand how and why keeping > the control on the JMPs sizes is of major interrest, doesn't > show anything but your own level of stupidity, troll. No, it simply shows that the RosAsm designer doesn't know the first thing about language design and how things like branch displacement size should be independent of local vs. global labels (two independent things, if there ever was one). Cheers, Randy Hyde
From: randyhyde@earthlink.net on 14 Mar 2006 11:01 Betov wrote: > "sevagK" <kahlinor(a)yahoo.com> écrivait news:1142301695.148972.226240 > @j52g2000cwj.googlegroups.com: > > > Rosasm macros have been shown to produce *less* quality assembly code. > > > ???!!!... By who? When? Where? How could User Defined > Macros output anything but what is written by the > Programmer? Compare MASM's ..if eax == ebx . . . .if ecx == edx . . . .else . . . .endif ..else . . . ..endif Against comparable code produced by your macros. You'll discover that MASM produces better code.
From: randyhyde@earthlink.net on 14 Mar 2006 11:04 Betov wrote: > > Pathetic Troll, RosAsm is an _ASSEMBLER_: Yes, though not a very good one. > > 1) The JMPs sizes are under the control of the programmer. Unless, of course, you tell it to optimize branch lengths. Then it does a poor job of optimizing those (provably not as good as MASM or FASM). > > 2) The commented out line has nothing to do with this. > > 3) RosAsm does not "break". It simply tells you where > you did an error, and shows you the line, so that you > could choose the long form, if this is really what you > mean to do. Period. Of course, other assemblers automatically fix this for you. And most of them will let you force a long or short jump (with an error, if a forced jump is out of range) if that's what you really need. Most people *never* need to specifically control the branch size, so it makes *far* more sense to make branch optimization the default case. And certainly, you *don't* want to tie the size of the branch displacement to the type of the target label, as RosAsm does. These are independent concepts. It's poor language design to couple them the way you have. Cheers, Randy Hyde
From: randyhyde@earthlink.net on 14 Mar 2006 11:22
Betov wrote: > > Seriously, my competency level in OS Programming is, so > to say,... Negative. Why limit yourself to OS programming. You've amply demonstrated this to be true for assemblers and disassemblers, too :-) > > :) > > > When you first told me about ReactOS, it was nothing but plans. I > > thought it was going to be permanent vaporware. > > > The very first day i heard of it, in September 1998, i started > RosAsm. Too bad you weren't smart enough to start RosAsm for Linux. Which *was* real at the time. That way, you wouldn't be in the ethical position of griping about Microsoft while continuing to support them. > > >and when they get it 100% "clean", M$'ll bury 'em in lawyers > > anyway... :( > > This will not happend, dispiting Randall Hyde sweet dreams. Like I really care. I have no problems with ReactOS whatsoever at all. If they get it working and MS doesn't come after them -- great! One more OS that HLA runs under. But I'm a realist. There is no way I'd base any business plan on ReactOS. If you think SCO and Linux was bad, just wait until Microsoft gets going on this. > If it could happend, they would already have sued WINE, First of all, Wine is a completely different animal. And second, just because they haven't sued the Wine developers yet doesn't mean they never will. But as it is, Wine is not, and never will be, a threat to Windows. ReactOS could be. And Microsoft does not respond well to threats to Windows, particularly if those doing the threatening have violated patents in Windows. It's a shame it has to be that way, but anyone who thinks Microsoft will just ignore ReactOS is fooling themselves. > and > the main reason why they can't do this, is that it would be > a massive counter publicity for them. They have plenty of > resources, - technical and commercial -, for assuming the > competition, without much problems. Why waste money and resources fighting something that is continually "two years away"? No sense shutting it down until it becomes a real threat. Until then, let those "open source" programmers waste time on this project rather than doing something that might really damage MS and something that MS *can't* sue over. MS is rather devious, you know? Cheers, Randy Hyde |