"We Never Use Assembly Language"
in [ASM]
|
From: Betov on 11 Mar 2006 03:56 o//annabee <fack(a)szmyggenpv.com> ?crivait news:op.s58c7v0rce7g4q(a)bonus: > HLA is written in C. You spent 9 years with this. By the way, this point say all and everything, about Assembly productivity: 9 years for a simple HLL Pre- Parser, written in Flex, Bison, and C, whereas the Macros Parsers of all of the actual Assemblers, have been written in, at most, one or two years, in Self-Compilable Assembly. Betov. < http://rosasm.org >
From: toby on 11 Mar 2006 14:19 randyhyde(a)earthlink.net wrote: > Check out > http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt > > This is a talk Tim Sweeny gave on programming languages at POPL (a very > high-end programming languages conference) on language design goals > that game programmers are interested it. Despite the obvious knock > against using assembly language, it discusses several language features > that game programmers want (and why assembly is bad). > > Of course, there is the quote "we will gladly give up 10% of our > performance for 10% improved productivity." Yep: He's wrong - it's probably more like 100% or more improved productivity. And what about the benefits of portability? > Does this also mean they'll > give up 50% of the performance for 50% productivity? :-) Interestingly > enough, this was in the section that discussed how important > performance is. > Cheers, > Randy Hyde
From: rhyde on 11 Mar 2006 15:51 toby wrote: > > Of course, there is the quote "we will gladly give up 10% of our > > performance for 10% improved productivity." > > Yep: He's wrong - it's probably more like 100% or more improved > productivity. Well, whether he was wrong or right, the fact that he would give up 10% performance for so little productivity gain is disturbing in and of itself. Heck, you can generally get 50% better productivity just by better management, without affecting the code one iota. After all, the pareto principle (80/20 rule) applies there, too. Although programmer productivity and program efficiency aren't exactly independent variables, they are not lock-step dependent on one another, either. > > And what about the benefits of portability? Now that Apple is moving to Intel chips, this issue is becoming less and less important for game developers. Within five years, for example, I doubt anyone will care if the latest and greatest game runs on a PowerPC chip anymore than they care if it runs on an Alpha or MIPS chip today. Cheers, Randy Hyde
From: rhyde on 11 Mar 2006 15:55 Betov wrote: > o//annabee <fack(a)szmyggenpv.com> écrivait news:op.s58c7v0rce7g4q(a)bonus: > > > HLA is written in C. You spent 9 years with this. Oh, and don't forget the four books written during this time period, the full-time job, and other activities.... Unlike one particular assembler author claims, I've not spent 12 hours/day seven days a week working on my assembler. > > By the way, this point say all and everything, about Assembly > productivity: 9 years for a simple Simple? Hmmm... If only RosAsm had such simple features. :-) > HLL Pre- Parser, written > in Flex, Bison, and C, whereas the Macros Parsers of all of > the actual Assemblers, have been written in, at most, one or > two years, in Self-Compilable Assembly. And that shows. That's one of the main reasons HLA's compile-time language and macro processor is far more sophisticated than the ones found in all the hobby assemblers. And for someone who has spent 7 years working on such a simple product as RosAsm, show assembler doesn't hold a candle to features found in HLA, you're not exactly on solid ground with your insults here. There's an old saying: "people who live in glass houses shouldn't throw stones". Cheers, Randy Hyde
From: toby on 11 Mar 2006 17:22
rhyde(a)cs.ucr.edu wrote: > toby wrote: > > > > Of course, there is the quote "we will gladly give up 10% of our > > > performance for 10% improved productivity." > > > > Yep: He's wrong - it's probably more like 100% or more improved > > productivity. > > Well, whether he was wrong or right, the fact that he would give up 10% > performance for so little productivity gain is disturbing in and of > itself. Heck, you can generally get 50% better productivity just by > better management, without affecting the code one iota. Okay, I concede. A macro assembler can be very productive. All other requirements being equal :-) > After all, the > pareto principle (80/20 rule) applies there, too. Although programmer > productivity and program efficiency aren't exactly independent > variables, they are not lock-step dependent on one another, either. > > > > > And what about the benefits of portability? > > Now that Apple is moving to Intel chips, this issue is becoming less > and less important for game developers. Few people in the wider computing community seem to realise this, but perfect platform transparency in an operating system is nothing new. Of those I've used, SunOS achieved it (between SPARC and m68k); ULTRIX achieved it (VAX and MIPS); NEXTSTEP achieved it (between m68k, Intel, PA-RISC and SPARC) - completely foreshadowing OS X (PPC, PPC64 and x86); and of course Linux (a dozen architectures) and NetBSD (several dozens) achieve it too, not to mention the other BSDs and probably a few dozen other portable systems. But this is completely off topic for an assembler group, because assembly just can't help here. > Within five years, for example, > I doubt anyone will care if the latest and greatest game runs on a > PowerPC chip anymore than they care if it runs on an Alpha or MIPS chip > today. > Cheers, > Randy Hyde |