mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (04/01/91)
In article <dillon.5751@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >>>In article <mykes.0250@sega0.SF-Bay.ORG> mykes@sega0.SF-Bay.ORG (Mike Schwartz) writes: >... >>> >>>Yeah - the men realize that choosing the right tool for the job makes >>>them more productive; the boys don't realize that doing everything in >>>assembler does little more than make them overworked. >>> >> >>'C' is hardly ever the right tool for games. I use it a lot when I use >>my Amiga as a workstation, but if it weren't for the fact that I have >>a 68030, the performance would suck. >> >>Jim Goodnow used 'C' to write his assembler (as), and HiSoft used >>Assembler language. AS is > 50K and is a slow pig. Devpac is 27K on >>disk and is blindingly fast. Which is the right tool? I don't care >>how hard YOU think it is for HiSoft to maintain the source to their >>assembler, but ME the consumer cares how it performs. Genim2 is the >>ONLY assembler on the market that performs as it is documented, and it >>has NO bugs. I have bought every other assembler and they all are >>deficient and larger. > > This is amusing, because you are making a blanket statement about > two similar products written in different languages. You are assuming > that C, generally, is a sludgepile compared to assembly. > > Well, I am happy to say that you are dead wrong! The primary difference > in speed between Manx AS and DevPak is NOT that one is written in C and > the other is written in assembly, but in the ALGORITHMS used... things > like symbol table searching and such. > > It is true that hand optimized assembly is faster, but not that much > faster than a program written in C by the same programmer (the keyword). > Obviously, a C program will only run as well as the programmer > programs, same goes with assembly. > > DAS, the assembler in DICE, while it doesn't implement a few things > like INCLUDE and macros, is on-par with DevPak and only half as fast as > ArgAsm in all other comparisons (ArgAsm is blindingly fast not only > because it written in assembly, but also written by an expert > programmer). So here you have DAS in C and DevPak in assembly and, > lo!, they are the same speed! And, gee, it took me a week to write > DAS, I wonder how long it took them to write DevPak? ArgAsm took > several months to write in assembly, I believe. That's a good return > on my investment, I think. > > Even so, much of the difference between ArgAsm and DAS can be > attributed to the fact that ArgAsm is a one-pass assembler while DAS > is a two-pass. So in terms of efficiency ArgAsm, written by an > expert programmer, is only a little more efficient than DAS. If I > were to rewrite DAS as a one-pass assembler it would be comparable. > > Now you get to the nitty gritty... how can ArgAsm get away with being a > one pass assembler? It makes various assumptions, requires XREF's to > occur before usage, and makes additional assumptions for branches. DAS > is a two pass assembler because it does major branch size optimizations > and Bcc-to-Bra optimizations more suited to the assembly output of the > compiler. Actually, internally, DICE is a 5 pass assembler but only > two of the passes do major computation. > > So, don't make blanket statements about C and assembly please. > > -Matt > >-- > > Matthew Dillon dillon@Overload.Berkeley.CA.US > 891 Regal Rd. uunet.uu.net!overload!dillon > Berkeley, Ca. 94708 > USA Someone posted to the net a few days ago that Matt Dillon's DAS assembler is the fastest/best 68000 assembler around. Well, I collect assemblers in my constant search for better/faster onces, so I downloaded DICE to check out the assembler. Well, whoever it was that recommended it must not use assembler language for much, because DAS is NOT much of an assembler. When you invoke it from the command line, it prints the following message: @($)DAS V2.06.04 Feb 14 1991 (c)Copyright 1990 by Matthew Dillon, All Rights Reserved DAS is a minimal assembler which accepts output from DC1. DAS infile -o outfile We who use assembler language don't use "minimal" assemblers. This assembler is useless to us, but it doesn't claim to be useful to do anything but assembling the output of Matt's compiler. Who is kidding who here? No offense to Matt, but to say this is an assembler is a joke. It no doubt assembles whatever DC1 generates, but DC1 can't be using much of the 68000 instruction set if it expects DAS to assemble it. In Matt's behalf, his assembler does what it's advertised to do. The poster of the article was responding to my posting claiming that Manx AS is a slow pig when compared to Devpac or Adapt. He also says that Adapt is not a good assembler. Adapt and Devpac are both written in assembler language, and Manx is written in 'C'. The results are appropriate for the language used. ANY ALGORITHM, when coded in both 'C' and assembler will benefit from assembler language, even a bubble sort. Well, just for yuks, I decided to try to benchmark the assemblers in question. I used a disassembler to make source code from the CygnusEd executable and ran it through each of the 4 assemblers. Unfortunately, DAS is totally incapable of assembling much in the way of assembler language and refused to assemble the source. I was able to get the other three assemblers to work, though, so I thought I would post the results. Remember that both Devpac and Adapt generate executables without needing a linker, so any Manx AS benchmark should include the linker phase required to make the executable. This is unfortunate, but it is required to build a working CED from the disassembled source code. If there does exist some version of DAS that works, the same consideration goes for it. Maybe Matt can spend an extra day to add the feature. I used DSM from OTG Software to make the disassembled ced.asm file. The file is 816364 bytes and consists of 29483 lines of source code. In case some of you think that this is not a fair benchmark, I create large source files with CED for all my assembly work. Assembling a large source file is the only valid benchmark for what I use the assemblers for. I have an Amiga 2000/30 (25MHz 68030 with 4MB 32bit memory) and a GVP 80Meg hard card with FAAASTROMs installed. The benchmarks were done from the same partition on my harddisk, so any fragmentation hinders each assembler in the same manner. The results: DEVPAC ced.asm (816364 bytes) -> ced.genim (116640 bytes) 1:15 MANX ced.asm (816364 bytes) -> ced.o (115980 bytes) 1:41 ln ced.o crashes, so no benchmark possible ADAPT ced.asm (816364 bytes) -> ced.hx (116636 bytes) :46 Here is what I get when I try to use DAS: DAS: Line 28644 Error Unrecognized opcode: DCB DAS: Line 28656 Error Unrecognized opcode: DCB DAS: Line 28657 Error Unrecognized opcode: DCB DAS: Line 28664 Error Unrecognized opcode: DCB DAS: Line 28677 Error Unrecognized opcode: DCB DAS: Line 28683 Error Unrecognized opcode: DCB DAS: Line 28688 Error Unrecognized opcode: DCB DAS: Line 28691 Error Unrecognized opcode: DCB DAS: Line 28964 Error Unrecognized opcode: DCB DAS: Line 28965 Error Unrecognized opcode: DCB DAS: Line 28993 Error Unrecognized opcode: DCB DAS: Line 29128 Fatal-Error ran out of memory Here is my memory usage: Type Available In-Use Maximum Largest chip 865432 174720 1040152 862824 fast 2487472 1706800 4194272 2477824 total 3352904 1881520 5234424 3340648 When I make the max possible RAM configuration (by quitting CED), I get output that looks like this from DAS: DAS: Line 428 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 433 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 446 Error Illegal addressing mode(s) 9 0 for BGE DAS: Line 458 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 461 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 469 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 471 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 477 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 515 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 518 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 544 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 551 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 559 Error Illegal addressing mode(s) 9 0 for BRA DAS: Line 563 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 565 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 567 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 584 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 586 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 598 Error Illegal addressing mode(s) 9 0 for BSR DAS: Line 600 Warning Extra garbage: RTS DAS: Line 610 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 614 Error Illegal addressing mode(s) 9 0 for BNE DAS: Line 615 Error Illegal addressing mode(s) 9 0 for BSR DAS: Line 627 Error Illegal addressing mode(s) 9 0 for BEQ DAS: Line 629 Error Illegal addressing mode(s) 9 0 for BCS It also printed to stderr (I couldn't capture it) a bunch of messages like: Expected register! reglist got d0-d4,-(a7) -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/02/91)
In article <mykes.1002@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > >Someone posted to the net a few days ago that Matt Dillon's DAS >assembler is the fastest/best 68000 assembler around. Well, I collect >assemblers in my constant search for better/faster onces, so I >downloaded DICE to check out the assembler. > >Well, whoever it was that recommended it must not use assembler language >for much, because DAS is NOT much of an assembler. When you invoke it >from the command line, it prints the following message: > > >@($)DAS V2.06.04 Feb 14 1991 >(c)Copyright 1990 by Matthew Dillon, All Rights Reserved >DAS is a minimal assembler which accepts output from DC1. >DAS infile -o outfile > > >We who use assembler language don't use "minimal" assemblers. This >assembler is useless to us, but it doesn't claim to be useful to do BLAST IT MIKE, WILL YOU FOR ONCE RESEARCH YOUR !#$%#$% ANSWERS? DAS was never meant to be a general purpose assembler... it was written SOLELY to assemble the output from DC1 for my DICE compiler system. BUT, you can still use DAS to compare assembly verses C for what DAS *does* implement. The fact is that, everything being proportional, If I were to implement macros and includes for DAS tomorrow they would be at the same level of performance as the rest of DAS. *THAT* was the @#$#@ point of the article, which you seem to miss entirely. You seem eager to find fault with everything said but in your eagerness you decidedly MISS much of the points of the posted articles. >anything but assembling the output of Matt's compiler. Who is kidding >who here? No offense to Matt, but to say this is an assembler is a >joke. It no doubt assembles whatever DC1 generates, but DC1 can't >be using much of the 68000 instruction set if it expects DAS to >assemble it. In Matt's behalf, his assembler does what it's advertised >to do. Excuse me, except for macros and includes DAS does a pretty damn good job assembling *all* 68000 instructions... there were a few missing in 2.06.04 but they are all implemented now. It will even optimize forward referenced branches to byte or word according to distance, something the compiler relies on but also something quite useful for hand assembly, I think. >The poster of the article was responding to my posting claiming that >Manx AS is a slow pig when compared to Devpac or Adapt. He also says >that Adapt is not a good assembler. Adapt and Devpac are both written >in assembler language, and Manx is written in 'C'. The results are >appropriate for the language used. ANY ALGORITHM, when coded in both >'C' and assembler will benefit from assembler language, even a bubble >sort. You are missing the point yet again... the reason MANX's AS is so slow has NOTHING to do with the fact that is was coded in C, but has EVERYTHING to do with the fact that slow algorithms were chosen. >Well, just for yuks, I decided to try to benchmark the assemblers in >question. I used a disassembler to make source code from the CygnusEd >executable and ran it through each of the 4 assemblers. Unfortunately, >DAS is totally incapable of assembling much in the way of assembler >language and refused to assemble the source. I was able to get the >... >Here is what I get when I try to use DAS: > >DAS: Line 28644 Error Unrecognized opcode: DCB >DAS: Line 28656 Error Unrecognized opcode: DCB >DAS: Line 28657 Error Unrecognized opcode: DCB >DAS: Line 28664 Error Unrecognized opcode: DCB >DAS: Line 28677 Error Unrecognized opcode: DCB >DAS: Line 28683 Error Unrecognized opcode: DCB >DAS: Line 28688 Error Unrecognized opcode: DCB >DAS: Line 28691 Error Unrecognized opcode: DCB >DAS: Line 28964 Error Unrecognized opcode: DCB >DAS: Line 28965 Error Unrecognized opcode: DCB >DAS: Line 28993 Error Unrecognized opcode: DCB >DAS: Line 29128 Fatal-Error ran out of memory OH GIVE ME A BREAK. You really like making these blanket statements don't you? Try DC.B, even then you might have to change some of the data types because DAS does not implement all of them. >output that looks like this from DAS: > >DAS: Line 428 Error Illegal addressing mode(s) 9 0 for BNE >.. >It also printed to stderr (I couldn't capture it) a bunch of >messages like: > >Expected register! reglist got d0-d4,-(a7) > Um, why don't you POST the lines in question instead of the error messages, it might become more clear as to the problem. Illegal addressing mode 9 is ABSOLUTE-LONG .. let me guess, you had lines like: beq $5000 due to the disassembly, which is illegal. On the otherhand, beq $234(pc) is legal... >-- >******************************************************** >* Appendix A of the Amiga Hardware Manual tells you * >* everything you need to know to take full advantage * >* of the power of the Amiga. And it is only 10 pages! * >******************************************************** Look, up until this posting I have been able to keep my temper in control, but this takes the cake... you simply ignore what you do not want to here, you don't bother to research what you are doing (you didn't bother to read the DAS documentation), and you give up at the smallest inconvenience without even TRYING to figure out the problem. You don't even TRY, and while I can accept that when you blast other people's stuff without blowing my top, I can't accept that when you blast MY stuff so blatently. You aren't thinking. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jesup@cbmvax.commodore.com (Randell Jesup) (04/02/91)
In article <mykes.1002@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >Someone posted to the net a few days ago that Matt Dillon's DAS >assembler is the fastest/best 68000 assembler around. Well, I collect >assemblers in my constant search for better/faster onces, so I >downloaded DICE to check out the assembler. No, they responded to your comment that assemblers written in C were far slower than assemblers written in assembler. >Well, whoever it was that recommended it must not use assembler language >for much, because DAS is NOT much of an assembler. When you invoke it >from the command line, it prints the following message: It's not supposed to be a general-purpose stand-alone assembler. It does what it's designed to do. >We who use assembler language don't use "minimal" assemblers. This >assembler is useless to us, but it doesn't claim to be useful to do >anything but assembling the output of Matt's compiler. Who is kidding >who here? No offense to Matt, but to say this is an assembler is a >joke. It no doubt assembles whatever DC1 generates, but DC1 can't >be using much of the 68000 instruction set if it expects DAS to >assemble it. In Matt's behalf, his assembler does what it's advertised >to do. As you noted, Matt doesn't try to say it's a useful tool for people writing in asm. He did say that it is as fast as some assemblers written in assembler, in response to your comments about the Aztec 'as' assembler, which is also meant primarily for assembling the output of a compiler. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)