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.