Small-C revisited

Small-C revisited

[Ken Martwick]

After the initial success of porting an (MS-DOS) version
of Small-C to ELKS, progress has been minor.  My first
try was to port "as86" to ELKS.  After a "chmem" problem
that I still don't understand, the assembler is to the
point of starting and just hanging.  Even if it could be
made to work, it would need great modification to deal
with the MASM-like assembly code generated by Small-C.
An inviting alternative is to port the assembler which
was written to accompany Small-C.  It supposedly can be
compiled with Small-C, but I have not yet found a ver-
sion that is compatible.  Neither have I had success in
compiling it with "bcc"; there are many incompatibilities
in the old pre-ANSI dialects of "C".  Even if it could
be made to compile, it still might be wrong.  If these
problems could be solved, there is still need for pro-
viding a compatible library and linker.  Perhaps it may
be a more rewarding effort to port "bcc".  There is a
lot more awareness of its peculiarities.  Splitting it
into two or three programs might make a generally use-
ful program which could compile utilities if not the
ELKS shell.
Ken Martwick
 

Re: Small-C revisited

[Riley Williams]

Hi Ken.

> After the initial success of porting an (MS-DOS) version of Small-C
> to ELKS, progress has been minor. My first try was to port "as86" to
> ELKS. After a "chmem" problem that I still don't understand, the
> assembler is to the point of starting and just hanging.

One obvious question: What memory model is small-C set to? The various
MS-DOS compilers normally had a means of selecting different memory
models, with trade-offs between various facilities, and it's possible
that small-C is defaulting to the wrong memory model.

> Even if it could be made to work, it would need great modification
> to deal with the MASM-like assembly code generated by Small-C.

The simplest way of dealing with that would be to write a separate
preprocessor that converts from one to the other. Assembly language
is invariably one statement per line, so that wouldn't be hard to do.

> An inviting alternative is to port the assembler which was written
> to accompany Small-C. It supposedly can be compiled with Small-C,
> but I have not yet found a version that is compatible.

That's probably more a question of finding the right compiler switches
rather than anything else.

> Neither have I had success in compiling it with "bcc"; there are
> many incompatibilities in the old pre-ANSI dialects of "C". Even
> if it could be made to compile, it still might be wrong.

I've just finished converting the ELKS kernel source to ANSI, so I'd
be interested in having a go at doing the same here.

> If these problems could be solved, there is still need for providing
> a compatible library and linker.

True.

> Perhaps it may be a more rewarding effort to port "bcc". There is a
> lot more awareness of its peculiarities. Splitting it into two or
> three programs might make a generally useful program which could
> compile utilities if not the ELKS shell.

That's also true.

Best wishes from Riley.

Re: Small-C revisited

[Alan Cox]

On Wed, 2002-06-05 at 04:23, Ken Martwick wrote:
> of Small-C to ELKS, progress has been minor.  My first
> try was to port "as86" to ELKS.  After a "chmem" problem
> that I still don't understand, the assembler is to the
> point of starting and just hanging.  Even if it could be

Our current binary format is the minix one and has the same design flaw.
Minix doesn't support swapping so allocates a program data as

		Data
		<space>
		Stack

And brk()/malloc etc expand into pre-reserved space. Chmem adjusts that
space. What probably should happen since we do have swap is that we
allocate

		Stack (size configured at compile/link time)
		Data

We can then actually expand the program space if need be. On v7 swap is
activated at boot up and they basically did

		if(room to just grow a bit)
			grow_it()
		else
			swap_it_out()

and the swap back in would sort out a suitable sized chunk.

Re: Small-C revisited

[Alan Cox]

On Wed, 2002-06-05 at 04:23, Ken Martwick wrote:
> sion that is compatible.  Neither have I had success in
> compiling it with "bcc"; there are many incompatibilities
> in the old pre-ANSI dialects of "C".  Even if it could
> be made to compile, it still might be wrong.  If these
> problems could be solved, there is still need for pro-
> viding a compatible library and linker.  Perhaps it may
> be a more rewarding effort to port "bcc".  There is a
> lot more awareness of its peculiarities.  Splitting it
> into two or three programs might make a generally use-
> ful program which could compile utilities if not the
> ELKS shell.

I've been pondering the question of how to make bcc fit. One way is a
better optimiser, but the other approach that might be easier to
implement would be an optional 'size before speed' piece of code.

Take the entire existing tree, scan it for identical sequences of asm
instructions where the stack is balanced (ie equal push/pop and never
pops below the level on entry) generate a library of them and then
replace those sequences with calls if bcc is called with some suitable
option to run the replacer. We'd trade a few clock cycles for bytes each
time the substitution occurred.

That way bcc would probably actually fit 

Re: Small-C revisited

[Manuel Novoa III]

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

Hello,

On Wed, Jun 05, 2002 at 06:31:23PM +0100, Alan Cox wrote:
> I've been pondering the question of how to make bcc fit. One way is a
> better optimiser, but the other approach that might be easier to
> implement would be an optional 'size before speed' piece of code.
> 
> Take the entire existing tree, scan it for identical sequences of asm
> instructions where the stack is balanced (ie equal push/pop and never
> pops below the level on entry) generate a library of them and then
> replace those sequences with calls if bcc is called with some suitable
> option to run the replacer. We'd trade a few clock cycles for bytes each
> time the substitution occurred.
> 
> That way bcc would probably actually fit 
> 

As an interim approach, you could try just #ifdef-ing out the floating
point support.  I just ran a quick test of simply removing floatop.c
from the dependencies and #ifdef'ing out the necessary code blocks in
genloads.c, glogcode.c, softop.c, hardop.c, and assign.c.  It buids,
and at least the preprocessor works with elksemu.  I'm not sure what
compiler misbehavior might result if any floating point code is
encountered though.

[mjn3@mars bcc]$ file bcc bcc-cc1
bcc:     Linux-8086 executable
bcc-cc1: Linux-8086 executable
[mjn3@mars bcc]$ size86 bcc bcc-cc1
text    data    bss     dec     hex     filename
11776   1328    744     13848   3618    bcc
65424   5896    8848    80168   13928   bcc-cc1

This is for bcc from dev86-0.16.3, but with some additional tweaks to
the preprocessor to support "#elif" and non-ansi token pasting macros,
as well as enabling the "asm" statement outside of a function so that
I could do things like the following (bcc patch for this is attached).
I meant to post the patch sometime before this, but I've been pretty
busy with some uClibc projects.

Manuel


/* Put this immediately before the function being aliased. */
#define __BCC_ALIAS(X,Y)        asm("export _" "X" "\n_" "X" " = _" "Y")

#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


[-- Attachment #2: bcc.diff --]
[-- Type: text/plain, Size: 3118 bytes --]

--- declare.c-dist	Fri Dec 17 11:51:13 1999
+++ declare.c	Sun Apr 21 18:55:33 2002
@@ -36,6 +36,7 @@
 FORWARD void declselt P((struct typestruct *structype, offset_T *psoffset,
 			 struct typelist ** ptypelist));
 FORWARD bool_pt declspec P((void));
+FORWARD void doasm2 P((void));
 FORWARD struct typestruct *declsu P((void));
 FORWARD void idecllist P((void));
 FORWARD void initarray P((struct typestruct *type));
@@ -47,6 +48,23 @@
 FORWARD void rdeclarator P((void));
 FORWARD bool_pt regdecl P((void));
 
+PRIVATE void doasm2()
+{
+    lparen();
+    if (sym!=STRINGCONST)
+    	error("string const expected");
+    else {
+	nextsym();
+	constant.value.s[charptr-constant.value.s]='\0';
+	outnstr("!BCC_ASM");
+	outbyte('\t');
+	outnstr(constant.value.s);
+	outnstr("!BCC_ENDASM");
+	rparen();
+	semicolon();
+    }
+}
+
 PRIVATE struct typestruct *chainprefix(pretype, sufftype)
 struct typestruct *pretype;
 struct typestruct *sufftype;
@@ -487,6 +505,10 @@
 	case UNSIGNDECL:
 	    ++nunsigned;
 	    nextsym();
+	    break;
+	case ASMSYM:
+	    nextsym();
+	    doasm2();
 	    break;
 	default:
 	    goto break2;
--- preproc.c-dist	Sat Jan 12 12:02:18 2002
+++ preproc.c	Sun Apr 21 18:55:43 2002
@@ -53,6 +53,7 @@
 FORWARD void asmcontrol P((void));
 FORWARD void control P((void));
 FORWARD void defineorundefinestring P((char *str, bool_pt defineflag));
+FORWARD void elifcontrol P((void));
 FORWARD void elsecontrol P((void));
 FORWARD void endif P((void));
 FORWARD fastin_pt getparnames P((void));
@@ -193,7 +194,7 @@
     }
     ctlcase = symptr->offset.offsym;
     if (ifstate.ifflag == FALSE &&
-	(ctlcase < ELSECNTL || ctlcase > IFNDEFCNTL))
+	(ctlcase < ELIFCNTL || ctlcase > IFNDEFCNTL))
 	return;
     switch (ctlcase)
     {
@@ -209,6 +210,9 @@
     case DEFINECNTL:
 	define();
 	break;
+    case ELIFCNTL:
+	elifcontrol();
+	break;
     case ELSECNTL:
 	elsecontrol();
 	break;
@@ -345,7 +349,14 @@
 		gch1();
 		skipcomment();
 		/* comment is space in modern cpp's but they have '##' too */
+#if 0
 		ch = *--lineptr = ' ';
+#else
+		/* With this, we can define a paste macro. */
+		--lineptr;
+		gch1();
+		continue;
+#endif
 	    }
 	}
 #ifdef TS
@@ -495,6 +506,29 @@
 	    }
 	    skipline();
 	}
+    }
+}
+
+/* elifcontrol() - process #elif */
+
+PRIVATE void elifcontrol()
+{
+    if (iflevel == 0)
+    {
+	error("elif without if");
+	return;
+    }
+    if (ifstate.elseflag) {
+	register struct ifstruct *ifptr;
+
+	ifptr = &ifstack[(int)--iflevel];
+	ifstate.elseflag = ifptr->elseflag;
+	ifstate.ifflag = ifptr->ifflag;
+
+	ifcontrol(IFCNTL);
+    } else {
+	ifstate.ifflag = ifstate.elseflag;
+	ifstate.elseflag = FALSE;
     }
 }
 
--- table.c-dist	Sat Mar 16 04:28:26 2002
+++ table.c	Sun Apr 21 18:55:58 2002
@@ -30,7 +30,7 @@
 #define MAXEXPR 500
 #endif
 #define MAXLOCAL 100
-#define NKEYWORDS 35
+#define NKEYWORDS 36
 #ifdef NOFLOAT
 #define NSCALTYPES 10
 #else
@@ -116,6 +116,7 @@
 
     { "#asm", ASMCNTL, },
     { "#define", DEFINECNTL, },
+    { "#elif", ELIFCNTL, },
     { "#else", ELSECNTL, },
     { "#endasm", ENDASMCNTL, },
     { "#endif", ENDIFCNTL, },

Re: Small-C revisited

[Harry Kalogirou]

Την Τετ, 05-06-2002 στις 20:27, ο/η Alan Cox έγραψε:
 
> Our current binary format is the minix one and has the same design flaw.
> Minix doesn't support swapping so allocates a program data as
> 
> 		Data
> 		<space>
> 		Stack
> 
> And brk()/malloc etc expand into pre-reserved space. Chmem adjusts that
> space. What probably should happen since we do have swap is that we
> allocate
> 
> 		Stack (size configured at compile/link time)
> 		Data
> 
> We can then actually expand the program space if need be. On v7 swap is
> activated at boot up and they basically did
> 
> 		if(room to just grow a bit)
> 			grow_it()
> 		else
> 			swap_it_out()
> 
> and the swap back in would sort out a suitable sized chunk.
> 

That is what I was planning to implement next. I'm currently working on
making an efficient memory defrager but I got bored when the ELKS tree
got uncompilable.

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