[net.micro.68k] 68K software standardization with small-C

68K (01/15/83)

	Why not start out on the right foot among us 68K users and
begin with  small_C, small_VM, small_shell, and small_VOS  as the 
central core of software on our systems?  I propose that since
small_Cv2.0 is public domain, we should port it to the 68K and make
it our standard for a beginning system.  In this manner, we would be
able to exchange programs over phone lines with  'C' source as the software
medium using a modem for the hardware.  Our hardware could be much different
and the underlying (sp?) operating system different as long as the 
virtual operating system interface was there for the interface.

	A good discussion of the value of a virtual operating system
is found in the Communications of the ACM, Sept 80, Volume 23, Number 9.

"Small VM", Nucleus of a Portable Software Development Environment is
written up in Dr. Dobb's Journal issue 61 (Nov 81).
"Small Shell" Part 2 of a North* VOS, is written up in DDJ 63 (Jan 82).

In the Dec 82, and Jan 83 issues of DDJ small-Cv.2 is written up.  
You will find the address of J. E. Hendrix in the Dec. 82 issue.
He sells documentation and disks for Northstar and CP/M format.
He orginated the small-VM and small-shell.

I am looking for someone who would like to help port the small-Cv2.0
and a OS of sorts over to the 68K for standardization among us small
guys that don't carry around 'K' bucks for a system and software.

Also look at the benefit of being compatible with the 8 bitters.
Exchange of programs across the line with no mods for a running program!
Maybe someone out there running Flex09 would like to port small-C and
small-VM to run on a 6809 or 6800 microprocessor.  This particular
port would produce a gateway to share software with the CP/M folks
who have small-C.   Get the picture.   I hope so. 
	How about some activity on this net for us with 68K home
computers.   By the way I am still soldering my hardware up yet.
SOON, I will need to write software to make my dumb rock (silicon)
work and talk to me (terminal io).  
	Trying to do well,   fredf  ~~~~~!decvax!microsof!uw-beaver!fredf

 

patcl (01/16/83)

A standardization effort for "small" 68K systems (ie., systems which
are affordable or buildable by individuals, as opposed to $15,000 Unix
workstations) is definitely a good idea. Hope we get a lot more
discussion on this. I don't like the idea of standardizing on a
particular language, however. I think the "virtual machine" should be
defined at a lower lever, and should perhaps be restricted to I/O driver
calls. Standardization of disk I/O is particularly critical.

Does anyone know what the (rumored) forthcoming "low-end" Apple 68K system
(not Liza/Lisa, the other one) will provide for an OS?

wagner (02/01/83)

I dont have a 68K, so I dont really enter into this discussion
directly, but I do have a 6809, and some other things, and I
was looking to small C v2 to solve some problems for me as a
standard amongst my various machines and amongst my various
friends machines in the neighbourhood.  I am trying now to
get it up on UNIXtm as a first step to porting it to my
6809, and trying is the right word.  The language it is
written in is close enough to C to fool the unaided eye, but
it sure dont fool the compilers.  I dont mind a subset C
compiler, but I mind a compiler that accepts syntax outside
the language (not extentions, just bugs).  The compiler itself
misuses stdio so badly that it wont compile with UNIX stdio.
Some examples:
1) the files are all declared int instead of FILE *.
   The solution appears to be to change them all to FILE *,
   and then, in the header files,
#ifndef UNIX
#define FILE int
#endif
   and then change his support routines to expect *int instead
   of int.  Eventually, of course, he should be passing more
   info than just an int around if he wants to do things right,
   but at least this gives him the option of leaving the shape 
   of a FILE "variable" to the stdio.h file.
2) He tries in several places to read from stderr.  Needless to
   say, UNIXtm isnt amused.
3) He is forever assigning pointers to ints and back again.
   This happens to work on machines where pointers and ints
   are the same size (11/70, 8080+Z80) but will it work on
   new 16bit machines?  Will it keep working?  Memories are 
   getting cheaper, and already there are machines whose
   address space is bigger than the intuitive size of an int
   on that machine.
4) He #ifdefs himself to death, making the code very hard to
   read in sections.
5) He confuses int op[16]  (an array of 16 ints) with
           int (*op[16])() (an array of 16 pointers to functions returning int).
6) His include syntax is different from standard C for no 
   obvious reason.
7) From the code it would appear that #includes cannot be
   nested (I havent tried this)
	
	I now have the thing working, sort of, under UNIX.
At least it stopped giving me core dumps if I stick to the
straight and narrow and dont give it bad file names.
It might be possible to make it work sensibly under UNIX
with a lot more work.  It isnt obvious that it would then
compile itself any more.  I am trying to isolate UNIX changes
in ifdef UNIX sections, but it isnt always obvious what it will
and wont compile itself.
	But, and this is a big but, it seems to have the 
8080 architecture hard-wired into it, and ripping that out
will be more work again.  I must say, to its credit, that it
is a great improvement over release 1 of the compiler, which
was even more stuck in the 8080 grove.
	Fixing all these things up might be more work than
writing a proper subset compiler.  Does anyone else working
on this compiler have any thoughts on the subject?

Michael Wagner, UTCS

P.S. Perhaps I should have put this submission into net.micro
     rather than just the 68K part.  Forgive me.  I will copy
     it into the right place; it just seemed initially better
     to follow up the discussion on standardization on Smallc.