From: mjn3@codepoet.org (Manuel Novoa III)
To: Robert de Bath <robert$@mayday.cix.co.uk>
Cc: Riley Williams <rhw@InfraDead.Org>,
Harry Kalogirou <harkal@gmx.net>,
Linux-8086 <linux-8086@vger.kernel.org>
Subject: Re: C compiler, assembler and linker
Date: Mon, 22 Jul 2002 18:46:11 -0600 [thread overview]
Message-ID: <20020723004611.GA9657@codepoet.org> (raw)
In-Reply-To: <1c289c8ad98ba628@mayday.cix.co.uk>
Hello Robert,
On Tue, Jul 23, 2002 at 12:26:52AM +0100, Robert de Bath wrote:
> On Mon, 15 Jul 2002, Manuel Novoa III wrote:
> > 3) Support asm() at file scope. This is to allow the equivalent
> > of #asm/#endasm in macros.
>
> Hmm, interesting, I'll have to look at this ... carefully.
I mainly use this for defining aliases for functions. For example,
in an object file for the labs function I could write
#define strong_alias(Y,X) asm("export _" "X" "\n_" "X" " = _" "Y");
strong_alias(labs,imaxabs)
long int labs(long int j)
{
return (j >= 0) ? j : -j;
}
which would make imaxabs an alias for labs (at least when optimizing).
I also use this with bcc auto-run functions. I'm sure you'll recognize
the following. Allowing asm() at file scope, I can hide the implementation
details with a macro where I couldn't with #asm/#endasm.
#ifdef __AS386_16__
#define __BCC_CTOR(X) asm( \
" loc 1\n" /* Make sure the pointer is in the correct segment */ \
"auto_func:\n" /* Label for bcc -M to work. */ \
".word _" "X" "\n" /* Pointer to the autorun function */ \
".word no_op\n" /* Space filler cause segs are padded to 4 bytes. */ \
".text\n" /* So the function after is also in the correct seg. */ \
)
#endif
#ifdef __AS386_32__
#define __BCC_CTOR(X) asm( \
" loc 1\n" /* Make sure the pointer is in the correct segment */ \
"auto_func:\n" /* Label for bcc -M to work. */ \
".long _" "X" "\n" /* Pointer to the autorun function */ \
".text\n" /* So the function after is also in the correct seg. */ \
)
#endif
> > 4) Limited support for things like "#define stdio stdio". Stock bcc
> > goes into an infinite loop when encounting this. The implementation
> > has flaws, but it does what I needed. You see this a lot in the
> > glibc headers we're using with uClibc (yes I'm working on a port).
>
> I don't like the way this is done; I think it'd be better to 'smudge'
> the definition of the current macro so that the search can't find the
> word for recursion.
I don't like the way it is done either... but it was quick and it
allowed me to avoid special-casing lots of uClibc (glibc) headers.
> > 5) Improved condition wrapping of the floating point related code in
> > the bcc source (working towards building bcc for elks). As I said,
> > the code generator dies... at least using elksemu.
>
> I'd suspect the dtype or fltype variables.
I still haven't had time to investigate this. :-(
Manuel
next prev parent reply other threads:[~2002-07-23 0:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-14 14:05 C compiler, assembler and linker Harry Kalogirou
2002-07-14 17:27 ` Manuel Novoa III
2002-07-15 6:07 ` Riley Williams
2002-07-15 17:02 ` Manuel Novoa III
2002-07-15 19:13 ` Riley Williams
2002-07-15 22:02 ` Manuel Novoa III
2002-07-16 6:27 ` Riley Williams
2002-07-17 1:31 ` Manuel Novoa III
2002-07-17 6:33 ` Riley Williams
2002-07-18 12:03 ` Minix vs. ELKS Feher Tamas
2002-07-18 12:27 ` Javier Sedano
2002-07-02 15:07 ` (unknown) Miguel A. Bolanos
2002-07-18 13:40 ` Minix vs. ELKS Alan Cox
2002-07-22 21:41 ` C compiler, assembler and linker Robert de Bath
2002-07-23 8:16 ` Robert de Bath
2002-07-23 16:25 ` Manuel Novoa III
2002-07-23 19:09 ` Robert de Bath
2002-07-24 21:17 ` More dev86 changes (0.16.5) Robert de Bath
2002-07-24 22:02 ` Riley Williams
2002-07-25 15:42 ` Manuel Novoa III
2002-07-26 7:55 ` Robert de Bath
2002-07-26 15:12 ` Manuel Novoa III
2002-07-26 8:22 ` Robert de Bath
2002-07-24 22:26 ` Paul Nasrat
2002-07-25 16:34 ` Manuel Novoa III
2002-07-22 23:26 ` C compiler, assembler and linker Robert de Bath
2002-07-23 0:34 ` Riley Williams
2002-07-23 0:58 ` Manuel Novoa III
2002-07-23 0:46 ` Manuel Novoa III [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-07-15 14:16 Ken Martwick
2002-07-15 19:21 ` Riley Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020723004611.GA9657@codepoet.org \
--to=mjn3@codepoet.org \
--cc=harkal@gmx.net \
--cc=linux-8086@vger.kernel.org \
--cc=rhw@InfraDead.Org \
--cc=robert$@mayday.cix.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.