cvs.gedasymbols.org/archives/browse.cgi   search  
Mail Archives: djgpp/1997/10/06/01:58:02

From: baldo AT chasque DOT apc DOT org
Message-Id: <3.0.1.32.19971006011953.00689fb0@chasque.apc.org>
Date: Mon, 06 Oct 1997 01:19:53 -0300
To: Derek Greene <topcoder AT mindspring DOT com>
Subject: Re: Why not build in inline 80x86 assembly, like in borland C
Cc: djgpp AT delorie DOT com
In-Reply-To: <34364680.1361@mindspring.com>
References: <34361EA4 DOT BFFADE9E AT worldonline DOT nl>
Mime-Version: 1.0

At 09:37 AM 04/10/1997 -0400, you wrote:
>Reinier Heeres wrote:
>> 
>> Hi!
>> 
>> I would like to know if there are any other guys who'd like to see
>> NORMAL 80x86 assembly inline in their programs? Why isn't it build in?
>> Only because of the portability???
>> 
>> Reinier
>> 
>persoanlly i would love to see it, but, that would be hard to
>incorperate-sorta-you see, djgpp was made from the original gnu source,
>just ported and changed so it would compile :)
>
>it is made so it would compile unix/linux programs with little or no
>changes at all, so making inline assembly use intel syntax would ruin
>that, plus he would have to do alot of changing of the gcc code, plus
>as.exe would need to be changed...in short it would create one big mess
>
	I think that it would be nice to incorporate the Intel Sintax without
removing the support for At&T sintax. For example using asm_intel() keyword
for that matter and the normal asm() for At&T.
	This would help people porting diverse programs with inline intel assembly
sintax. I think that the Intel sintax is very important like the At&T
sintax, so it must be also supported.

	Thats my opinion. Goodbye!

Ivan Baldo: baldo AT chasque DOT apc DOT org - http://www.chasque.apc.org/baldo

- Raw text -


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