(unknown)

(unknown)

[Miguel A. Bolanos]

unsubscribe linux-8086

C compiler, assembler and linker

[Harry Kalogirou]

Hi Ken,

 as I recall you was working on making the smallC compiler work under
ELKS. What is the status of it? I checked the as86 and ld86 and both
compile fine with bcc(hope they don't need more than 64KB of data) so we
probably just need a compiler now. Can you brief us on it?

Harry

Re: C compiler, assembler and linker

[Manuel Novoa III]

Harry,

On Sun, Jul 14, 2002 at 05:05:55PM +0300, Harry Kalogirou wrote:
> 
> Hi Ken,
> 
>  as I recall you was working on making the smallC compiler work under
> ELKS. What is the status of it? I checked the as86 and ld86 and both
> compile fine with bcc(hope they don't need more than 64KB of data) so we
> probably just need a compiler now. Can you brief us on it?

I don't know about small C, but I managed to get bcc to build itself for
elks by omitting all the floating point related code.  The preprocessor
appears to work, but the code generator dies.  I haven't had time to
track down the problem(s).

Manuel

Re: C compiler, assembler and linker

[Riley Williams]

Hi Manuel.

>> as I recall you was working on making the smallC compiler work under
>> ELKS. What is the status of it? I checked the as86 and ld86 and both
>> compile fine with bcc(hope they don't need more than 64KB of data)
>> so we probably just need a compiler now. Can you brief us on it?

> I don't know about small C, but I managed to get bcc to build itself
> for elks by omitting all the floating point related code. The pre-
> processor appears to work, but the code generator dies. I haven't
> had time to track down the problem(s).

Could you perhaps advise re the tweaks you have done so far? That way,
we can add a few more brain cells working on sorting the problem out...

Best wishes from Riley.

Re: C compiler, assembler and linker

[Manuel Novoa III]

Hi Riley,

On Mon, Jul 15, 2002 at 07:07:27AM +0100, Riley Williams wrote:
> > I don't know about small C, but I managed to get bcc to build itself
> > for elks by omitting all the floating point related code. The pre-
> > processor appears to work, but the code generator dies. I haven't
> > had time to track down the problem(s).
> 
> Could you perhaps advise re the tweaks you have done so far? That way,
> we can add a few more brain cells working on sorting the problem out...

Hopefully I'll have time this evening to sort out a patch to post.
I found that dev86-0.16.3 has a number of build issues, so I had to
modify some of the makefiles, etc. as well.

Anyway, here's a list of my bcc tweaks (as best I recall):

1) #elif support.
2) #warning support (at least for non-continued lines).
3) Support asm() at file scope.  This is to allow the equivalent
   of #asm/#endasm in macros.
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).
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.

Manuel

Re: C compiler, assembler and linker

[Riley Williams]

Hi Manuel.

>>> I don't know about small C, but I managed to get bcc to build
>>> itself for elks by omitting all the floating point related code.
>>> The preprocessor appears to work, but the code generator dies.
>>> I haven't had time to track down the problem(s).

>> Could you perhaps advise re the tweaks you have done so far? That
>> way, we can add a few more brain cells working on sorting the
>> problem out...

> Hopefully I'll have time this evening to sort out a patch to post. I
> found that dev86-0.16.3 has a number of build issues, so I had to
> modify some of the makefiles, etc. as well.

That I can certainly understand...

> Anyway, here's a list of my bcc tweaks (as best I recall):

> 1) #elif support.
>
> 2) #warning support (at least for non-continued lines).
>
> 3) Support asm() at file scope. This is to allow the equivalent
>    of #asm/#endasm in macros.
>
> 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).
>
> 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.

Can I add some wish-list items:

  6) True support for the "signed" keyword. At the moment, any file
     using it has to include a "#define signed" line to remove it for
     bcc, and in some cases, even that isn't enough as the code stops
     working as a result.

  7) At least a warning message if any unrecognised options are given
     on the command line. At the moment, unrecognised options are just
     silently ignored!

Also, are there any plans to get these included in the primary bcc code?

Best wishes from Riley.

Re: C compiler, assembler and linker

[Manuel Novoa III]

Riley,

On Mon, Jul 15, 2002 at 08:13:01PM +0100, Riley Williams wrote:
> Can I add some wish-list items:

I've only been adding some features, like #elif and #warning, that I
tend to use in my uClibc code.  My main interest isn't in working on
bcc, but in reducing the work I need to do in porting uClibc to elks.

>   6) True support for the "signed" keyword. At the moment, any file
>      using it has to include a "#define signed" line to remove it for
>      bcc, and in some cases, even that isn't enough as the code stops
>      working as a result.

Yes, I know.  bcc supports only unsigned char.  Coding around that
limitation can be a pain.

>   7) At least a warning message if any unrecognised options are given
>      on the command line. At the moment, unrecognised options are just
>      silently ignored!

Probably not worth doing at the moment because the main bcc driver was
rewritten recently and is probably still in flux.

> Also, are there any plans to get these included in the primary bcc code?

I had planned to send my patches to the dev86 maintainer.  When I get
the patch cleaned up and post it here, I'll also forward it on to
Robert de Bath... although I've seen him post to this list on occassion.

Manuel

Re: C compiler, assembler and linker

[Riley Williams]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1954 bytes --]

Hi Manuel.

>> Can I add some wish-list items:

> I've only been adding some features, like #elif and #warning, that I
> tend to use in my uClibc code. My main interest isn't in working on
> bcc, but in reducing the work I need to do in porting uClibc to
> elks.

Fair enough, although those two are real niggles to me...

>> 6) True support for the "signed" keyword. At the moment, any file
>>    using it has to include a "#define signed" line to remove it for
>>    bcc, and in some cases, even that isn't enough as the code stops
>>    working as a result.

> Yes, I know. bcc supports only unsigned char. Coding around that
> limitation can be a pain.

Unfortunately, that's not actually true. It's very easy to prove that
bcc uses SIGNED chars if the unsigned keyword isn't specifically given.
Robert also states that bcc does not correctly handle signed chars, so
this default rather worries me.

As it happens, I emailed a patch to Robert back on 6th June 2002 that
added and correctly implemented the signed keyword in the declspec
function, thus dealing with most of the problem. There may be a few
corner cases left where signed will cause problems, but I haven't seen
any of them yet. I've attached a gzip'd copy of that patch to this email
for reference...

>> 7) At least a warning message if any unrecognised options are
>>    given on the command line. At the moment, unrecognised options
>>    are just silently ignored!

> Probably not worth doing at the moment because the main bcc driver
> was rewritten recently and is probably still in flux.

Fair enough, I wasnae aware of that...

>> Also, are there any plans to get these included in the primary bcc
>> code?

> I had planned to send my patches to the dev86 maintainer. When I get
> the patch cleaned up and post it here, I'll also forward it on to
> Robert de Bath... although I've seen him post to this list on
> occassion.

That's good to hear...

Best wishes from Riley.





[-- Attachment #2: allow signed in bcc --]
[-- Type: APPLICATION/x-gzip, Size: 4742 bytes --]

Re: C compiler, assembler and linker

[Manuel Novoa III]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

Hi Riley,

Didn't have time yesterday to generate the patch, but here it is.
Some of the build changes only make sense if you aren't installing
in the default locations as root.

As a refresher, it adds #elif support, #warning support (for
non-continued lines), asm() at file scope, limited support for
recursive #define (#define stdin stdin), and more complete exclusion
of the floating point related code when floats are disabled.  This
lets you build bcc for elks.  As I mentioned earlier, it looks like
the preprocessor works but it dies when trying to do code generation.

On Tue, Jul 16, 2002 at 07:27:21AM +0100, Riley Williams wrote:
> Unfortunately, that's not actually true. It's very easy to prove that
> bcc uses SIGNED chars if the unsigned keyword isn't specifically given.
> Robert also states that bcc does not correctly handle signed chars, so
> this default rather worries me.

Can you send me a simple test app to illustrate this?  Thanks.

> As it happens, I emailed a patch to Robert back on 6th June 2002 that
> added and correctly implemented the signed keyword in the declspec
> function, thus dealing with most of the problem. There may be a few
> corner cases left where signed will cause problems, but I haven't seen
> any of them yet. I've attached a gzip'd copy of that patch to this email
> for reference...

I'm looking forward to trying out your patch in a few days when things
slow down for me.

Manuel

[-- Attachment #2: dev86-0.16.3-diff.gz --]
[-- Type: application/octet-stream, Size: 7494 bytes --]

Re: C compiler, assembler and linker

[Riley Williams]

Hi Manuel.

> Didn't have time yesterday to generate the patch, but here it is.
> Some of the build changes only make sense if you aren't installing
> in the default locations as root.
>
> As a refresher, it adds #elif support, #warning support (for
> non-continued lines), asm() at file scope, limited support for
> recursive #define (#define stdin stdin), and more complete exclusion
> of the floating point related code when floats are disabled. This
> lets you build bcc for elks. As I mentioned earlier, it looks like
> the preprocessor works but it dies when trying to do code generation.

I'll have a look at it anyway...

>> Unfortunately, that's not actually true. It's very easy to prove
>> that bcc uses SIGNED chars if the unsigned keyword isn't
>> specifically given. Robert also states that bcc does not correctly
>> handle signed chars, so this default rather worries me.

> Can you send me a simple test app to illustrate this? Thanks.

Not needed in this case - just read through the declspec() function
definition and you see that bcc internally uses SIGNED types for
everything unless the unsigned keyword is specifically given. There is
absolutely nothing in there to make char different from int.

I mentioned this to Robert when I sent in the patch referred to above,
and he confirms that the language analyser does indeed select on that
basis. However, he implied that the code generator will use unsigned for
char even when the language analyser says they should be signed, so
there is presumably some hack for this that really wants to be removed.

The patch I enclosed last time simply adds the ability to select either
signed or unsigned in the language analyzer and end up with the correct
result. It doesn't touch any hack such as the above.

>> As it happens, I emailed a patch to Robert back on 6th June 2002
>> that added and correctly implemented the signed keyword in the
>> declspec function, thus dealing with most of the problem. There may
>> be a few corner cases left where signed will cause problems, but I
>> haven't seen any of them yet. I've attached a gzip'd copy of that
>> patch to this email for reference...

> I'm looking forward to trying out your patch in a few days when
> things slow down for me.

Many thanks.

Best wishes from Riley.

Minix vs. ELKS

[Feher Tamas]

Hello all,

I would like to ask for your opinion:

When will ELKS become an alternative for Minix, considering practical usability
for an end-user, who does a moderate amount of programming work (mostly
customizing the OS for his/her personal needs and writing small utils)? The
hardware is 80186 with PCMCIA slot, fastest and reliable serial port
functionality is important.

-Will ELKS have a GUI? I heard Minix had some very basic X, about the time of
Minix version 1.5
-Will ELKS have LIM-EMS support? Someone started a work on EMS for Minix, but it
was never finished.
-Is there ELKS equivalent to Minix's DosRead/DosWrite/DosDir functionality to
access M$ FAT filesystem?

Thanks in advance, Sincerely: Tamas Feher.

Re: Minix vs. ELKS

[Javier Sedano]

Feher Tamas wrote:
> 
> When will ELKS become an alternative for Minix, considering practical usability
> for an end-user, who does a moderate amount of programming work (mostly
> customizing the OS for his/her personal needs and writing small utils)?

	The ELKS kernel is almost ready, and many applications are available.
	A distribution (EDE) is being integrated, but it is still far from
Minix and farder from Linux distributions. Anyway, it makes much easier
to install ELKS.
	The compiler is currently being worked on to be runned on ELKS, but it
is still work-in-progress.


> The
> hardware is 80186 with PCMCIA slot, fastest and reliable serial port
> functionality is important.
> 

	I don't know what this sentence means...

> -Will ELKS have a GUI? I heard Minix had some very basic X, about the time of
> Minix version 1.5

	Minix does not have X, neither other garphics system. Minix-vmd can run
XFree86, but Minix-vmd doesn't run on 8086.

	ELKS can run microwindow (search google), an X-like graphic
environment, but I have never done so.

> -Is there ELKS equivalent to Minix's DosRead/DosWrite/DosDir functionality to
> access M$ FAT filesystem?
> 

	You can try to compile those applications with bcc, and try to run on
ELKS, and report what happens.

-- 
Everytime I Find The Meaning Of Life, They Change It.
--------
Javier Sedano Jarillo      http://www.it.uc3m.es/~jsedano
 jsedano@dit.upm.es (*)
 jsedano@ieee.org

Re: Minix vs. ELKS

[Alan Cox]

On Thu, 2002-07-18 at 13:03, Feher Tamas wrote:
> When will ELKS become an alternative for Minix, considering practical usability
> for an end-user, who does a moderate amount of programming work (mostly
> customizing the OS for his/her personal needs and writing small utils)? The
> hardware is 80186 with PCMCIA slot, fastest and reliable serial port
> functionality is important.

Nobody has written any PCMCIA point enablers yet

> -Will ELKS have a GUI? I heard Minix had some very basic X, about the time of
> Minix version 1.5

Nanogui was working at some point.

> -Will ELKS have LIM-EMS support? Someone started a work on EMS for Minix, but it
> was never finished.

It actually doesn't look that hard, certainly not to use as a swap
device anyway. What I've been chasing and never found is docs to the I/O
programming for EMS boards. 

> -Is there ELKS equivalent to Minix's DosRead/DosWrite/DosDir functionality to
> access M$ FAT filesystem?

You should be able to build mtools on it

Re: C compiler, assembler and linker

[Robert de Bath]

On Wed, 17 Jul 2002, Riley Williams wrote:

> Not needed in this case - just read through the declspec() function
> definition and you see that bcc internally uses SIGNED types for
> everything unless the unsigned keyword is specifically given. There is
> absolutely nothing in there to make char different from int.
>
> I mentioned this to Robert when I sent in the patch referred to above,
> and he confirms that the language analyser does indeed select on that
> basis. However, he implied that the code generator will use unsigned for
> char even when the language analyser says they should be signed, so
> there is presumably some hack for this that really wants to be removed.

This is wrong; the default type for bcc's char is unsigned.

Bcc uses _three_ char types; unsigned, signed and the default type,
it looks like there was an aim to make the signedness of the default
type a run-time option. Some time back I tried to make this work,
however, there appear to be implicit assumptions that the 'default'
char type is an 'unsigned' char.

Riley's patch is just to add a 'signed' keyword but it caused "make
distribution" to fail so I didn't make a distribution with it in.
(logically enough ;-)

Anyway now I've been reminded I took a little time out over the
weekend and fixed the problem. So far the signed char type seems
to work properly and I've found no more breakages...

Version 0.16.4 has escaped ...

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: C compiler, assembler and linker

[Robert de Bath]

On Mon, 15 Jul 2002, Manuel Novoa III wrote:

> 1) #elif support.

Okay, reasonable.

> 2) #warning support (at least for non-continued lines).

Hmm, a bit primitive, but, wth, It'll do the job.

> 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.

> 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.

> 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.

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: C compiler, assembler and linker

[Riley Williams]

Hi Robert, Manuel.

>> 1) #elif support.

> Okay, reasonable.

I haven't had a chance to look at this yet, so this comment is probably
irrelevant, but...does this support handle the following correctly?

	#define MODE1
	#define MODE3

	#ifdef MODE1
	#  ifdef DEBUG
	#    define DBGMODE 1
	#  endif
	#elifdef MODE2
	#  define DBGMODE 2
	#elifdef MODE3
	#  define DBGMODE 3
	#else
	#  define DBGMODE 4
	#endif

	#ifndef DBGMODE
	#  define DBGMODE 0
	#endif

With at least one C compiler I've used over the years, DBGMODE ended up
with the value 3 rather than the value 1 that it should have in that case.

>> 2) #warning support (at least for non-continued lines).

> Hmm, a bit primitive, but, wth, It'll do the job.

>> 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.

>> 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).

One obvious optimisation is this: Where a #define has the same value for
its value as its name, the entire #define is treated as a comment. That
would deal with the above define, but could have problems with...

	#define stdio (stdio)

...which probably also fails with the old system.

> 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.

When are macros expanded? If they are expanded as they are met in the
code, the above can't cause a problem as the macro isn't defined until
after the value has been expanded. However, if the preprocessor reaps
all the macros and then expands them in a separate pass, recursion
problems are inevitable.

As an example of this, how is the following code handled?

	int main()
	{
		int VALUE = 7;

	#define VALUE 12

		printf("Test 1 = %d\n", VALUE );

	#undef VALUE

		printf("Test 2 = %d\n", VALUE );
		exit(0);
	}

Whilst not good coding, that code is perfectly valid K&R C but any
compiler that first reaps the #define/#undef statements and expands the
macros in a separate pass can produce faulty code in two different ways,
and can fail to compile in two other ways...

Best wishes from Riley.

Re: C compiler, assembler and linker

[Manuel Novoa III]

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

Re: C compiler, assembler and linker

[Manuel Novoa III]

Riley,

On Tue, Jul 23, 2002 at 01:34:21AM +0100, Riley Williams wrote:
> Hi Robert, Manuel.
> 
> >> 1) #elif support.
> 
> > Okay, reasonable.
> 
> I haven't had a chance to look at this yet, so this comment is probably
> irrelevant, but...does this support handle the following correctly?
> 
> 	#define MODE1
> 	#define MODE3
> 
> 	#ifdef MODE1
> 	#  ifdef DEBUG
> 	#    define DBGMODE 1
> 	#  endif
> 	#elifdef MODE2
> 	#  define DBGMODE 2
> 	#elifdef MODE3
> 	#  define DBGMODE 3
> 	#else
> 	#  define DBGMODE 4
> 	#endif
> 
> 	#ifndef DBGMODE
> 	#  define DBGMODE 0
> 	#endif
> 
> With at least one C compiler I've used over the years, DBGMODE ended up
> with the value 3 rather than the value 1 that it should have in that case.

I just tested.  Changing #elifdef to #elif defined( ), it gives
0 if DEBUG isn't defined, and 1 if DEBUG is defined.

> >> 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).
> 
> One obvious optimisation is this: Where a #define has the same value for
> its value as its name, the entire #define is treated as a comment. That
> would deal with the above define, but could have problems with...
> 
> 	#define stdio (stdio)
> 
> ...which probably also fails with the old system.

Treating the define as a comment wouldn't work, as all the subsequent
#ifdef stdio tests would fail.

> > 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.
> 
> When are macros expanded? If they are expanded as they are met in the
> code, the above can't cause a problem as the macro isn't defined until
> after the value has been expanded. However, if the preprocessor reaps
> all the macros and then expands them in a separate pass, recursion
> problems are inevitable.
> 
> As an example of this, how is the following code handled?
> 
> 	int main()
> 	{
> 		int VALUE = 7;
> 
> 	#define VALUE 12
> 
> 		printf("Test 1 = %d\n", VALUE );
> 
> 	#undef VALUE
> 
> 		printf("Test 2 = %d\n", VALUE );
> 		exit(0);
> 	}
> 
> Whilst not good coding, that code is perfectly valid K&R C but any
> compiler that first reaps the #define/#undef statements and expands the
> macros in a separate pass can produce faulty code in two different ways,
> and can fail to compile in two other ways...

Preprocessor output:

int main()
{
int VALUE = 7;


printf("Test 1 = %d\n",12 );


printf("Test 2 = %d\n",VALUE );
exit(0);
}

Manuel

Re: C compiler, assembler and linker

[Robert de Bath]

On Tue, 16 Jul 2002, Manuel Novoa III wrote:

> Some of the build changes only make sense if you aren't installing
> in the default locations as root.

Humm, Manuel, you do realise that it isn't necessary to install dev86
to use it don't you?

I just put these two lines in a script in my $HOME/bin directory.

#!/bin/sh -
exec /usr/src/linux_86/bin/ncc "$@"

and add the bcc bin directory to my path too if I need direct access to
the new as86 and ld86.

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: C compiler, assembler and linker

[Manuel Novoa III]

Robert,

On Tue, Jul 23, 2002 at 09:16:52AM +0100, Robert de Bath wrote:
> On Tue, 16 Jul 2002, Manuel Novoa III wrote:
> 
> > Some of the build changes only make sense if you aren't installing
> > in the default locations as root.
> 
> Humm, Manuel, you do realise that it isn't necessary to install dev86
> to use it don't you?

Yes, although I had some problems in the past.  Don't remember which
version though.  I had an older version of bcc installed (from the
linux distribution I was using) and at one point the newer bcc was
still calling the older bcc-cc1 unless I set BCC_EXEC_PREFIX.

> I just put these two lines in a script in my $HOME/bin directory.
> 
> #!/bin/sh -
> exec /usr/src/linux_86/bin/ncc "$@"

I use a similar script (with options and include path overrides), but I
was using bcc rather than ncc.

BTW, there was one other mod in my bcc patch that I forgot to mention.
Since bcc doesn't support ## for token pasting, I was using the old k&r
method (where /**/ doesn't get mapped to space as in ANSI C).  But

#define __PASTE(x,y) x/**/y

wasn't working for me, so I patched things so it would.  That was some
time ago though, so I don't know if it is still a problem with stock
bcc.

Oh yes, and I had modifed the flags for ncc in the dev86 build to
include -ansi because the ELKS headers have now been ansi-fied.

Manuel

Re: C compiler, assembler and linker

[Robert de Bath]

On Tue, 23 Jul 2002, Manuel Novoa III wrote:

> > I just put these two lines in a script in my $HOME/bin directory.
> >
> > #!/bin/sh -
> > exec /usr/src/linux_86/bin/ncc "$@"
>
> I use a similar script (with options and include path overrides), but I
> was using bcc rather than ncc.

That's the difference; ncc looks in directories relative to where it is
on the fielsystem, bcc looks in 'standard' places.

> BTW, there was one other mod in my bcc patch that I forgot to mention.
> Since bcc doesn't support ## for token pasting, I was using the old k&r
> method (where /**/ doesn't get mapped to space as in ANSI C).  But
>
> #define __PASTE(x,y) x/**/y
>
> wasn't working for me, so I patched things so it would.  That was some
> time ago though, so I don't know if it is still a problem with stock
> bcc.

I'd looked at that line several times but didn't do anything about it.
But it _is_ a K&R compiler so it probably should do K&R pasting.

> Oh yes, and I had modifed the flags for ncc in the dev86 build to
> include -ansi because the ELKS headers have now been ansi-fied.

XXXX Rant about BCC being a K&R compiler deleted!

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

More dev86 changes (0.16.5)

[Robert de Bath]

> 1) #elif support.
In 0.16.5
Do we want #elifdef too?

> 2) #warning support (at least for non-continued lines).
In 0.16.5

> 3) Support asm() at file scope.  This is to allow the equivalent
>    of #asm/#endasm in macros.
In 0.16.5

> 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).
Recursive defines are now trapped and skipped; it even protects against
problems like:

   #define x z
   #define y x
   #define z y
   x y z

> 6) True support for the "signed" keyword. At the moment, any file
>    using it has to include a "#define signed" line to remove it for
>    bcc, and in some cases, even that isn't enough as the code stops
>    working as a result.
In 0.16.5, including 'signed char' typedefs, casts, variables and
constant folding. AFAIK it all works as it should. However please
note the _default_ char type is still unsigned.

> 7) At least a warning message if any unrecognised options are given
>    on the command line. At the moment, unrecognised options are just
>    silently ignored!
The bcc.c driver now checks options it would pass to ld86 and warns if
there are any it doesn't know.

So in all this now compiles and generates correct code in both 16 and 32
bit modes:
(Or at least similar to: gcc -funsigned-char )

---CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE---
#include <stdio.h>
#include <errno.h>

#define strong_alias(Y,X) asm(\
   "export _" "X", \
   "_" "X" " = _" "Y" \
   );

#if __STDC__
#define comb(x,y) x##y
#warning Using Ansi combine
#elif __BCC__
#define comb(x,y) x/**/y
#warning Using bcc combine
#else
#define comb(x,y) x/**/y
#warning Using K&R combine
#endif

#define signed unsigned
#define unsigned signed

#ifdef signed
typedef signed char t_sc;
typedef comb(un,signed) char t_uc;
#endif

char c;
t_sc sc;
t_uc uc;

strong_alias(main,zulu);
main()
{
   int i1, i2, i3;

   c = -6;
   uc = -6;
   sc = -6;

   printf("%ld, ", (long)c);
   printf("%ld, ", (long)uc);
   printf("%ld\n", (long)sc);

   printf("%d, ", c);
   printf("%d, ", uc);
   printf("%d\n", sc);

   i1 = c; i2 = uc; i3 = sc;

   printf("%d, ", i1);
   printf("%d, ", i2);
   printf("%d\n", i3);

   i1 = (char) 200 + (char) 50;
   i2 = (t_uc) 200 + (t_uc) 50;
   i3 = (t_sc) 200 + (t_sc) 50;

   printf("%d, ", i1);
   printf("%d, ", i2);
   printf("%d\n", i3);

   c = 200; uc = 200; sc = 200;

   i1 = c  + (long) 50;
   i2 = uc + (long) 50;
   i3 = sc + (long) 50;

   printf("%d, ", i1);
   printf("%d, ", i2);
   printf("%d\n", i3);
}
---CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE---

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: More dev86 changes (0.16.5)

[Riley Williams]

Hi Robert.

>> 1) #elif support.

> In 0.16.5
> Do we want #elifdef too?

If we support it as a variant of #if then we also want it as a variant
of #elif as well, in my opinion. Therefore, we will want...

	#elif
	#elifdef
	#elifndef

...together with any other variants that may exist.

>> 2) #warning support (at least for non-continued lines).

> In 0.16.5

With or without the continued lines?

Also (inspired by the way it's used in your example below, but taken
from a C compiler I once used on a Burroughs B6700 mainframe), could
support be added for the following...

 a. #debug msg

	#ifdef DEBUG
	#warning msg
	#endif

 b. #debugn msg

	#ifndef DEBUG
	#warning msg
	#endif

 c. #info msg

	shell printf '%s:%d: %s\n' "__FILE_" __LINE__ "$msg" >&2

 d. #onerr msg

	#if ERRCOUNT > 0
	#info msg
	#if LEVEL > 0
	#error "Unexpected EOF due to #onerr level failure"
	#endif
	#endif

This last one states "If one or more errors occur prior to this point in
the source, display the file and line containing the #onerr statement
together with the stated message", but also has the requirement that if
the point where the line occurs is other than at the top level of the
source, the #onerr line is treated as an EOF marker. We didn't often use
it, but when it was used, it was often a life-saver...

>> 3) Support asm() at file scope. This is to allow the equivalent
>>    of #asm/#endasm in macros.

> In 0.16.5

Nodz.

>> 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).

> Recursive defines are now trapped and skipped; it even protects
> against problems like:
>
>	#define x z
>	#define y x
>	#define z y
>	x y z

Good.

>> 6) True support for the "signed" keyword. At the moment, any file
>>    using it has to include a "#define signed" line to remove it for
>>    bcc, and in some cases, even that isn't enough as the code stops
>>    working as a result.

> In 0.16.5, including 'signed char' typedefs, casts, variables and
> constant folding. AFAIK it all works as it should. However please
> note the _default_ char type is still unsigned.

That shouldn't be a problem though.

>> 7) At least a warning message if any unrecognised options are given
>>    on the command line. At the moment, unrecognised options are just
>>    silently ignored!

> The bcc.c driver now checks options it would pass to ld86 and warns
> if there are any it doesn't know.

Good. That will catch things like the original ELKS Makefile that passed
(amongst others) --nostdinc to bcc in SOME of the directories !!!

> So in all this now compiles and generates correct code in both 16
> and 32 bit modes: (Or at least similar to: gcc -funsigned-char )

I would like to see the code produe a warning for the fact that the
macro defenition for strong_alias() includes the terminating semicolon
that should never be present on macro definitions - and yes, I know the
Linux kernel uses several macros that break this rule. Linus himself
states that they're wrong, but they're so well embedded that it's more
hassle than it's worth to fix the problem...

One other thing I would like to see, which is an optimising measure more
than anything: When bcc lays out the variables at any level, if it sorts
them in descending order of size before laying them out, it will really
minimise the number of padding bytes needed to ensure correct alignment.
It is for this reason that when I am writing C code, I always list all
of the variables in descending size order, but the compiler could make
this irrelevant, as many other optimising measures have become totally
irrelevant over the years.

As an example...

	int fn(varlist...)
	{
		char c;
		long l;

		:
	}

...would be best laid out in memory in the order l,c rather than c,l as
listed since the former order means that no padding is needed at all
under any circumstances, whereas the latter could require 3 bytes of
padding to align the long on a 4-byte boundary.

Best wishes from Riley.

> ---CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE------CUT-HERE---
>
> #include <stdio.h>
> #include <errno.h>
> 
> #define strong_alias(Y,X) asm(\
>    "export _" "X", \
>    "_" "X" " = _" "Y" \
>    );

      ^
There's that evil semicolon...

> 
> #if __STDC__
> #define comb(x,y) x##y
> #warning Using Ansi combine
> #elif __BCC__
> #define comb(x,y) x/**/y
> #warning Using bcc combine
> #else
> #define comb(x,y) x/**/y
> #warning Using K&R combine
> #endif
> 
> #define signed unsigned
> #define unsigned signed
> 
> #ifdef signed
> typedef signed char t_sc;
> typedef comb(un,signed) char t_uc;
> #endif
> 
> char c;
> t_sc sc;
> t_uc uc;
> 
> strong_alias(main,zulu);
> main()
> {
>    int i1, i2, i3;
> 
>    c = -6;
>    uc = -6;
>    sc = -6;
> 
>    printf("%ld, ", (long)c);
>    printf("%ld, ", (long)uc);
>    printf("%ld\n", (long)sc);
> 
>    printf("%d, ", c);
>    printf("%d, ", uc);
>    printf("%d\n", sc);
> 
>    i1 = c; i2 = uc; i3 = sc;
> 
>    printf("%d, ", i1);
>    printf("%d, ", i2);
>    printf("%d\n", i3);
> 
>    i1 = (char) 200 + (char) 50;
>    i2 = (t_uc) 200 + (t_uc) 50;
>    i3 = (t_sc) 200 + (t_sc) 50;
> 
>    printf("%d, ", i1);
>    printf("%d, ", i2);
>    printf("%d\n", i3);
> 
>    c = 200; uc = 200; sc = 200;
> 
>    i1 = c  + (long) 50;
>    i2 = uc + (long) 50;
>    i3 = sc + (long) 50;
> 
>    printf("%d, ", i1);
>    printf("%d, ", i2);
>    printf("%d\n", i3);
> }

Re: More dev86 changes (0.16.5)

[Paul Nasrat]

On Wed, Jul 24, 2002 at 10:17:16PM +0100, Robert de Bath wrote:
> 
> > 1) #elif support.
> In 0.16.5

<snip>

Hi Rob,

To take Gregg's post to a tangent.

I'd quite like to at least attempt to contribute to linux-86/elks libc.
I've played with ucLibc and also dredged up some stuff in the cvs
repostiory merged from dev86 but not in dev86 releases, and that confuses
me...

It's moved since my last attempt to try and get involved (and failing
due to slackness)

http://cvs.uclinux.org/cgi-bin/cvsweb/uClibc/libc/inet/addr.c?rev=1.1&content-type=text/x-cvsweb-markup

I'd quite like to see dev86 with a cvs repository so I can look over
different versions to learn about things.  I'd understand if you don't
want to bother merging past stuff into a repostiory but just out of
curiosity in terms of compiler stuff, libc stuff, and asm I'd like to
be able to easily see the stuff you're doing.

I may not be good enough to contribute, but if you can at least cvs it,
and give access to that, it'd be an education.

Cheers

Paul

Re: More dev86 changes (0.16.5)

[Manuel Novoa III]

Robert and Riley,

First, thanks Robert for all the work you've done in integrating
and improving these changes.  It will certainly make my work easier.

On Wed, Jul 24, 2002 at 11:02:44PM +0100, Riley Williams wrote:
> >> 1) #elif support.
> 
> > In 0.16.5
> > Do we want #elifdef too?
> 
> If we support it as a variant of #if then we also want it as a variant
> of #elif as well, in my opinion. Therefore, we will want...
> 
> 	#elif
> 	#elifdef
> 	#elifndef
> 
> ...together with any other variants that may exist.


> Also (inspired by the way it's used in your example below, but taken
> from a C compiler I once used on a Burroughs B6700 mainframe), could
> support be added for the following...
> 
>  a. #debug msg
>  b. #debugn msg
>  c. #info msg
>  d. #onerr msg

#elif is C89.  While the others could be convenient at times, I know
that I wouldn't use them for portability reasons.

> I would like to see the code produe a warning for the fact that the
> macro defenition for strong_alias() includes the terminating semicolon
> that should never be present on macro definitions - and yes, I know the
> Linux kernel uses several macros that break this rule. Linus himself
> states that they're wrong, but they're so well embedded that it's more
> hassle than it's worth to fix the problem...

The trailing semicolon was strictly a convenience thing.  The uClibc
code contains several instances of strong_alias().  Generally where
it is used, there is no trailing semicolon.  This caused a problem
when building with bcc since, although the patch allowed asm() to be
used at file scope, it was still a statement and needed trailing
semicolon for bcc to be happy.  Rather than change all the offending
instances in uClibc at the time, I just put the ';' in the bcc macro
definition.  I've got no problem changing this before the port is
committed.

> One other thing I would like to see, which is an optimising measure more
> than anything: When bcc lays out the variables at any level, if it sorts
> them in descending order of size before laying them out, it will really
> minimise the number of padding bytes needed to ensure correct alignment.
> It is for this reason that when I am writing C code, I always list all
> of the variables in descending size order,

Same here.  ;-)

>                                            but the compiler could make
> this irrelevant, as many other optimising measures have become totally
> irrelevant over the years.

Manuel

Re: More dev86 changes (0.16.5)

[Manuel Novoa III]

Paul,

On Wed, Jul 24, 2002 at 11:26:32PM +0100, Paul Nasrat wrote:
> I'd quite like to at least attempt to contribute to linux-86/elks libc.
> I've played with ucLibc and also dredged up some stuff in the cvs
> repostiory merged from dev86 but not in dev86 releases, and that confuses
> me...

A little bit of history... uC-libc was the libc put together by the
uClinux people.  It included a lot of dev86 code, but I think that's
where the connection ends.  More than 2 years ago, Erik Andersen forked
a version and renamed it uClibc.  His goal was to have a small libc to
use with busybox.

I got involved with uClibc almost 2 years ago... not long after Erik
had grafted on the glibc headers.  In that time, most of the original
dev86 code in uClibc has been modified or completely replaced.  Of the
current subdirs in uClibc, I've written much of stdlib and most or all
of the code in stdio, string, time, ctype, locale, wctype, and wchar.
Most of that code was written with eventual porting to elks/bcc in mind
and currently builds with the appropriate sys headers.  I'm hoping to
have elks/bcc support in uClibc in the next couple of months.

> It's moved since my last attempt to try and get involved (and failing
> due to slackness)
> 
> http://cvs.uclinux.org/cgi-bin/cvsweb/uClibc/libc/inet/addr.c?rev=1.1&content-type=text/x-cvsweb-markup

uclibc.org is the primary site for uClibc.

> I'd quite like to see dev86 with a cvs repository so I can look over
> different versions to learn about things.  I'd understand if you don't
> want to bother merging past stuff into a repostiory but just out of
> curiosity in terms of compiler stuff, libc stuff, and asm I'd like to
> be able to easily see the stuff you're doing.
> 
> I may not be good enough to contribute, but if you can at least cvs it,
> and give access to that, it'd be an education.

You might also want to look at the busybox cvs repository at busybox.net.
Certainly most of the busybox applets are far more featureful than
their elkscmd counterparts, and many should be easy enough to seperate
out and port to elks.

Manuel

Re: More dev86 changes (0.16.5)

[Robert de Bath]

On Thu, 25 Jul 2002, Manuel Novoa III wrote:

> > One other thing I would like to see, which is an optimising measure more
> > than anything: When bcc lays out the variables at any level, if it sorts
> > them in descending order of size before laying them out, it will really
> > minimise the number of padding bytes needed to ensure correct alignment.
> > It is for this reason that when I am writing C code, I always list all
> > of the variables in descending size order,
>
> Same here.  ;-)

This gains you nothing unless you are in the habit of using single byte
char values even then there's gotya ...

In 32bit mode int and long are the same size.
In 16bit mode everything is aligned on 2 bytes boundries (including the stack).

In fact if you put them in _decending_ order of size you may actually
be hurting the code because the BP register points at the top (highest
memory address) of the current stack frame so the variables defined
first have the smallest offsets and can probably be accessed using
smaller (and possibly faster) instructions, however, this only applies
if the offset exceeds 128 bytes.

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: More dev86 changes (0.16.5)

[Robert de Bath]

On Wed, 24 Jul 2002, Riley Williams wrote:

> Hi Robert.
>
> >> 1) #elif support.
>
> > In 0.16.5
> > Do we want #elifdef too?
>
> If we support it as a variant of #if then we also want it as a variant
> of #elif as well, in my opinion. Therefore, we will want...
>
> 	#elif
> 	#elifdef
> 	#elifndef
>
> ...together with any other variants that may exist.

Actually, thinking about this, where do these 'def' varients come from
IIRC 'elif' is Ansi-C but I don't think the others are, plus of course
you can use "#elif defined(VARNAME)"

> >> 2) #warning support (at least for non-continued lines).
>
> > In 0.16.5
>
> With or without the continued lines?
Without so far, I'll probably fix it later; and add #error (as a specific)
oh and skipping '#pragma'.

> Also (inspired by the way it's used in your example below, but taken
> from a C compiler I once used on a Burroughs B6700 mainframe), could
> support be added for the following...
>
>  a. #debug msg
>  b. #debugn msg
>  c. #info msg
>  d. #onerr msg

Possibly useful but I've _never_ come across them before and never though
of them as (WIBNI). IMO the '#debug' ones are useless, they'd (maybe)
be used once per program and as you mentioned '#warning' does the job.

_IF_ I implemented them I don't think it'd be directly as this, possibly
as '#pragma' varients would be ok. ("#pragma toplevel" perhaps)

> I would like to see the code produe a warning for the fact that the
> macro defenition for strong_alias() includes the terminating semicolon
> that should never be present on macro definitions - and yes, I know the
> Linux kernel uses several macros that break this rule. Linus himself
> states that they're wrong, but they're so well embedded that it's more
> hassle than it's worth to fix the problem...

NO. Null statments are frequently required in C and it's _very_ difficult
to guess it one is wrong; I have come across a compiler that could be
configured to warn about them and tried it, PITA.

Even the specific case of a semicolon at the end of a macro is dubious
though more easily detected. If I were going to start adding style
warnings I'd start with the potentially damaging ones (eg = rather
than ==).

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                       <http://www.cix.co.uk/~mayday>

Re: More dev86 changes (0.16.5)

[Manuel Novoa III]

Robert,

On Fri, Jul 26, 2002 at 08:55:39AM +0100, Robert de Bath wrote:
> On Thu, 25 Jul 2002, Manuel Novoa III wrote:
> 
> > > One other thing I would like to see, which is an optimising measure more
> > > than anything: When bcc lays out the variables at any level, if it sorts
> > > them in descending order of size before laying them out, it will really
> > > minimise the number of padding bytes needed to ensure correct alignment.
> > > It is for this reason that when I am writing C code, I always list all
> > > of the variables in descending size order,
> >
> > Same here.  ;-)
> 
> This gains you nothing unless you are in the habit of using single byte

On occassion.  I know that on i386 I've seen gcc produce smaller code
when I declared some small counters or boolean values as char rather
than int.

> char values even then there's gotya ...
> 
> In 32bit mode int and long are the same size.
> In 16bit mode everything is aligned on 2 bytes boundries (including the stack).
> 
> In fact if you put them in _decending_ order of size you may actually
> be hurting the code because the BP register points at the top (highest
> memory address) of the current stack frame so the variables defined
> first have the smallest offsets and can probably be accessed using
> smaller (and possibly faster) instructions, however, this only applies
> if the offset exceeds 128 bytes.

Also relevant in structure defs if you're going to ref the structure via
a pointer.  Putting the most commonly referenced field first lets it be
referenced without an additional offset.  I think I saved about 100-200
bytes in the uClibc stdio code by doing that with the FILE struct.  Of
course, then you also may need to adjust the layout to avoid holes.

On the topic of bcc feature additions, things I've thought about are:
1) long long support since it is in C99 and (selfishly) since it would
   allow me to avoid rewriting a couple of uClibc functions.
2) wide char support, which of course, that brings up the question of
   whether or not wide chars be 16 bits (to save space) or 32 bits
   (for better compatibility) in 16 bit mode.

Also, I suppose we all wish for a better optimizer.  I'd love to not
have to resort to the "register char *" as loop counter hack anymore.

Manuel