Date: Sun, 19 Oct 1997 20:17:01 +0200 (IST) From: Genady Beryozkin Reply-To: Genady Beryozkin To: Eli Zaretskii cc: djgpp AT delorie DOT com Subject: Re: Why not build in inline 80x86 assembly, like in borland C In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 19 Oct 1997, Eli Zaretskii wrote: > > On Wed, 15 Oct 1997, Genady Beryozkin wrote: > > > The most rediculous thing about it is that when I debug my AT&T style > > code with that FSDB debugger, I get it back in INTEL style ! > > You mix two different things here. The assembly syntax (either Intel > or AT&T) may be different, but the machine language produced by the > assembler is the same in both cases! > No. I didn't. I just found it funny that after 3 days of trying to port some bcc/intel code into djgpp (learning the extended inline syntax [which is a great thing indeed] etc) I got my intel code back while debugging .. The internal rhdie disassembler does it in the AT&T style It's a pity that neither of the two debuggers shows the machine code (like TD) so i can ensure that ethe things are ok indeed. > The way machine code is *displayed* by a debugger depends on the > disassembler that is part of that debugger. It so happens that the > author of FSDB elected to make his disassembler produce Intel style. > Other debuggers may do it differently. > > > Assembler is supposed to be machine-dependent. > > Assembly *language* is indeed machine-dependent, but the assembler > need not change that much, if the overall structure and high-level > syntactic constructs of the language don't change. If you change > those as well, you will need to rewrite the Gas parser grammar for > every machine. Right now, every machine has its machine-dependent > files which describe e.g. the available registers etc., but most of > the assembler sources don't change. > Now when I think about it, I remember the tortures I have been through the PDP11 course. The syntax is symilar indeed, but It wasn't easier to me to write a AT&T 386 code. I never wrote a parser, so I really don't know about how much it can help. Also most of tghe 386 assembly code is written using INTEL syntax - it's only confusing - especially the source,destination order.. > (Btw, usually, the C compiler is machine-dependent as well, although > the C language is not. GCC is unique in that most of the compiler > don't change at all when you port it to another CPU. All you need to > produce is a bunch of files that describe the target machine.) > I hope to find some time to look in the sources . Will they compile with BCC ? > > I also agree that INTEL&TASM&MASM etc standard is a little more > > wide-used than AT&T standard - so why do you bother to waste your time > > just for compatibility with SPARC & other? > > Well, I ``waste my time'' in a variety of ways, but none of them is > because of the Gas syntax. I actually find AT&T style to be better > than Intel style. Using the AT&T style actually saves some waste of > time, because we need not bother writing a new assembler, we just use > the GNU Assembler as is. > That's true if you really write a code that should run on all kind of platforms. I only wrote for a PC, so I might be misjudging it. Genady. P.S. finally I made that timer code to work. where can i send it to share it with other people ? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Genady Beryozkin, c0467082 AT t2 DOT technion DOT ac DOT il | * -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- * | Homepage : http://t2.technion.ac.il/~c0467082 | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Fair is foul, and foul is fair. Hover through the fog and filthy air.