More dev86 changes (0.16.7)

More dev86 changes (0.16.7)

[Robert de Bath]

Rather than joining in this discussion I've been adding about a thousand
lines of new code (and another of old) to dev86. The result is a nice
shiny new CPP. My problem now is that I've run out of bugs in it and need
your help to find some more.  ;-)

Advantages:
 The new CPP is fully ansi capable including '#' '##' and '??='.
 It's also a proper K&R preprocessor if you want.

My next step will be to rip the old CPP out of bcc completely, hopefully
making it lots smaller and so small enough to easily fit in an ELKS a.out.

This version uses the new cpp by default, -e will make it fall back to
the old one (for the moment).

With this version __STDC__ is now defined as "1" not "0" as it was before
because cpp is now fully ansi compliant (crosses fingers).

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

Re: More dev86 changes (0.16.7)

[Manuel Novoa III]

Hello Robert,

On Fri, Aug 02, 2002 at 09:18:22PM +0100, Robert de Bath wrote:
> Rather than joining in this discussion I've been adding about a thousand
> lines of new code (and another of old) to dev86. The result is a nice
> shiny new CPP. My problem now is that I've run out of bugs in it and need
> your help to find some more.  ;-)

I'll be happy to give it a try, but it won't be until next week.
I just got a rush contract job that I need to have done by Monday.

> Advantages:
>  The new CPP is fully ansi capable including '#' '##' and '??='.
>  It's also a proper K&R preprocessor if you want.
> 
> My next step will be to rip the old CPP out of bcc completely, hopefully
> making it lots smaller and so small enough to easily fit in an ELKS a.out.
> 
> This version uses the new cpp by default, -e will make it fall back to
> the old one (for the moment).
> 
> With this version __STDC__ is now defined as "1" not "0" as it was before
> because cpp is now fully ansi compliant (crosses fingers).

Excellent!  Looking forward to trying it with my uClibc stuff.

Manuel

Re: More dev86 changes (0.16.7) [About the optimiser]

[Harry Kalogirou]

Hi Robert,

 lately I was studing the assembly code bcc was generating and I noticed
that it generates a lot of code like this :

mov ax, 6[bp]
mov bx, 8[bp]
xchg ax, bx

Will it be hard to convince the compiler to generate

mov ax, 8[bp]
mov bx, 6[bp]

instead?

Harry

Re: More dev86 changes (0.16.7) [About the optimiser]

[Robert de Bath]

On 3 Aug 2002, Harry Kalogirou wrote:

> Hi Robert,
>
>  lately I was studing the assembly code bcc was generating and I noticed
> that it generates a lot of code like this :
>
> mov ax, 6[bp]
> mov bx, 8[bp]
> xchg ax, bx
>
> Will it be hard to convince the compiler to generate
>
> mov ax, 8[bp]
> mov bx, 6[bp]
>
> instead?

There's aren't many places xchg is used by bcc, I'd guess this one is
shifting longs but it'd help a lot if you gave me some of the original
C code too.

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

Re: More dev86 changes (0.16.7) [About the optimiser]

[Robert de Bath]

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


On 3 Aug 2002, Harry Kalogirou wrote:

> mov ax, 6[bp]
> mov bx, 8[bp]
> xchg ax, bx

Actually, looking at it copt can do this easily just add the attached rules
to the end of rules.86 (or put them in the lib dir and use -Ols)

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

[-- Attachment #2: Type: APPLICATION/X-GZIP, Size: 1563 bytes --]

Re: More dev86 changes (0.16.7) [About the optimiser]

[Harry Kalogirou]

Την Σαβ, 03-08-2002 στις 14:31, ο/η Robert de Bath έγραψε:
> 
> On 3 Aug 2002, Harry Kalogirou wrote:
> 
> > mov ax, 6[bp]
> > mov bx, 8[bp]
> > xchg ax, bx
> 
> Actually, looking at it copt can do this easily just add the attached rules
> to the end of rules.86 (or put them in the lib dir and use -Ols)
> 
> -- 
> Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
>                                        <http://www.cix.co.uk/~mayday>

Thanks Robert!

Harry


-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: More dev86 changes (0.16.7)

[Manuel Novoa III]

Hello Robert,

Sorry it took so long to do some testing, but I've been swamped.

Tried to build some of my uClibc stuff and found a bug with the new cpp
that is illustrated with the following test case.

test.c:

   #define X  (1UL)

   #if X == 0
   #error this shouldn't happen
   #endif

With the new cpp, what shouldn't happen... does.
Here's the output for "ncc -ansi -E test.c".

   test.c:3: warning: Unexpected text following preprocessor command
   test.c:5: error: #error this shouldn't happen
   # 1 "test.c"

Output without -ansi is:

   # 1 "test.c"
   test.c:3: warning: Unexpected text following preprocessor command
   test.c:5: error: #error this shouldn't happen

Also, with the old cpp one could use "-I" to not include the default
include dirs.  This feature seems to be lacking in the new version.

Manuel

Re: More dev86 changes (0.16.7)

[Robert de Bath]

On Sat, 10 Aug 2002, Manuel Novoa III wrote:

> Hello Robert,
>
> Sorry it took so long to do some testing, but I've been swamped.
>
> Tried to build some of my uClibc stuff and found a bug with the new cpp
> that is illustrated with the following test case.
>
> test.c:
>
>    #define X  (1UL)
>
>    #if X == 0
>    #error this shouldn't happen
Oops, you _really_ shouldn't put that "single quote" there, ansi preprocessors
that follow the standard explicitly will whinge.


>    #endif
>
> With the new cpp, what shouldn't happen... does.
> Here's the output for "ncc -ansi -E test.c".
>
>    test.c:3: warning: Unexpected text following preprocessor command
>    test.c:5: error: #error this shouldn't happen
>    # 1 "test.c"
>
> Output without -ansi is:
>
>    # 1 "test.c"
>    test.c:3: warning: Unexpected text following preprocessor command
>    test.c:5: error: #error this shouldn't happen

Okay, "UL" is now added as a valid type specifier for integers.
However specifing the type will make no difference as the integer
type for preprocessor expressions is supposed to be the largest
available integer however you express it.

I'm not even sure specifing a type is actually legal, but I think it's
covered by the phrase "identifier-nondigit" in the syntax table.

> Also, with the old cpp one could use "-I" to not include the default
> include dirs.  This feature seems to be lacking in the new version.

That is a bug in the new bcc.c that's been there since it first appeared,
(Errm, 0.16.2) ho hum nobody noticed before. (Including me!!!)

Okay fixed, and I'll be uploading a new version tomorrow with those
and a few other changes.

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

Re: More dev86 changes (0.16.7)

[Manuel Novoa III]

Robert,

On Sat, Aug 10, 2002 at 09:28:14PM +0100, Robert de Bath wrote:
> 
> Okay, "UL" is now added as a valid type specifier for integers.
> However specifing the type will make no difference as the integer
> type for preprocessor expressions is supposed to be the largest
> available integer however you express it.
> 
> I'm not even sure specifing a type is actually legal, but I think it's
> covered by the phrase "identifier-nondigit" in the syntax table.

ANSI/ISO C99 seems to allow an integer suffix on integer constants
in the constant expressions following an #if.  At least, I don't
see anything indicating otherwise.

> > Also, with the old cpp one could use "-I" to not include the default
> > include dirs.  This feature seems to be lacking in the new version.
> 
> That is a bug in the new bcc.c that's been there since it first appeared,
> (Errm, 0.16.2) ho hum nobody noticed before. (Including me!!!)
> 
> Okay fixed, and I'll be uploading a new version tomorrow with those
> and a few other changes.

Great.  I should have time tomorrow to download it and run some more
tests.

Manuel

dev86-0.16.8 cpp bugs

[Manuel Novoa III]

Hello Robert,

Some bugs in 0.16.8's cpp I'm afraid.  Try the following.

Manuel



#define X 2
#define Y 4
#undef TEST

#if 1

#ifdef TEST
#warning in test
#if X >= 4
#warning x
#elif Y >= 4
#warning y
#else
#warning other
#endif
#else  /* TEST */
#warning not in test so should be no other warnings
#endif

#else

#ifndef TEST
#warning not in test so should be no other warnings
#else
#warning in test
#if X >= 4
#warning x
#elif Y >= 4
#warning y
#else
#warning other
#endif
#endif

#endif

Re: dev86-0.16.8 cpp bugs

[Robert de Bath]

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

On Sun, 11 Aug 2002, Manuel Novoa III wrote:

> Hello Robert,
>
> Some bugs in 0.16.8's cpp I'm afraid.  Try the following.

Okay, looks like I wasn't correctly ignoring nested #elif's.
The patch attached should fix that.

The type change for the if_stack allows it to work with any #if nesting
unless you make a nesting error (It will fail to detect some).

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


[-- Attachment #2: Type: TEXT/PLAIN, Size: 599 bytes --]

diff -Nurd linux86.old/cpp/cpp.c linux86/cpp/cpp.c
--- linux86.old/cpp/cpp.c	Sun Aug 11 07:33:57 2002
+++ linux86/cpp/cpp.c	Sun Aug 11 20:13:38 2002
@@ -83,7 +83,7 @@
 static int if_false = 0;
 static int if_has_else = 0;
 static int if_hidden = 0;
-static int if_stack = 0;
+static unsigned int if_stack = 0;
 
 struct arg_store {
    char * name;
@@ -905,6 +905,13 @@
 int type;
 {
    int ch = 0;
+   if(if_false && if_hidden)
+   {
+      if( type != 3 ) if_hidden++;
+      do_proc_tail();
+      return 0;
+   }
+
    if( type == 3 )
    {
       if( if_count == 0 )

Re: dev86-0.16.8 cpp bugs

[Manuel Novoa III]

Robert,

Applied your if-patch.diff and things seem to be working fine now.
Haven't noticed any other problems, but I'll continue testing.

Manuel