Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!cordelia!c164-bd
From: c164-bd@cordelia.uucp (John D. Mitchell)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Microsoft Assembler Complaints
Message-ID: <9393@pasteur.Berkeley.EDU>
Date: 3 Dec 90 04:00:48 GMT
References: <9078@pasteur.Berkeley.EDU> <1990Nov20.141330.13358@polyof.poly.edu> <9109@pasteur.Berkeley.EDU> <59413@microsoft.UUCP> <9385@pasteur.Berkeley.EDU> <OTTO.90Dec2080958@tukki.jyu.fi>
Sender: news@pasteur.Berkeley.EDU
Reply-To: c164-bd@cordelia.UUCP (John D. Mitchell)
Followup-To: comp.os.msdos.programmer
Organization: University of California, Berkeley
Lines: 23

In article <OTTO.90Dec2080958@tukki.jyu.fi> otto@tukki.jyu.fi (Otto J. Makela) writes:
>In article <9385@pasteur.Berkeley.EDU> c164-bd@katerina.uucp (John D. Mitchell) writes:
>   Oh yeah, any word about whether they are finally going to write the
>   assembler in assembly language (instead of C)?

>Should it make any difference ?  The fact that it's slow doesn't have very
>much to do with what language it's done in.  You can make assembler slower
>than molasses in frozen-over hell.

Of course, my comment comes more from a desire to question M-soft's
thinking than anything else.  Everything I have ever seen by them
is large and slow.  Yes, there's plenty I haven't seen.  Speed IS
an issue to many people.  Look at how well Borland's done.  You're
absolutely correct (if I am inferring correctly) that proper design
(algorithms, data structures, etc.) make a much larger impact then
language choice (where the languages are roughly comparable).  If
they can produce an assembler that's as fast as the current version
of TASM and is as easy to use then I'll check it out.  No more
quirky bugs, inconsistent macros, etc.  (Good luck! :-)

Thanks,
	John D. Mitchell
	johnm@cory.Berkeley.EDU