delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/19/14:29:13

Date: Sun, 19 Oct 1997 20:17:01 +0200 (IST)
From: Genady Beryozkin <c0467082 AT techst02 DOT technion DOT ac DOT il>
Reply-To: Genady Beryozkin <c0467082 AT techst02 DOT technion DOT ac DOT il>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Why not build in inline 80x86 assembly, like in borland C
In-Reply-To: <Pine.SUN.3.91.971019172327.27221W-100000@is>
Message-ID: <Pine.GSO.3.95.971019195419.5506A-100000@techst02.technion.ac.il>
MIME-Version: 1.0

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.


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019