) (03/06/90)
Lately I've been wondering about a few things:
Considering there are C compilers (well, atleast one) for the Apple II,
how possible is it to write the "assembly only" sections of unix, and then
compile the C sources for unix on a Apple II? I know it would require some
of the heavy dute memory expansions that AE makes for the apple II, but still..
I'm still using apple dos 3.3...I don't think I'd be terribly upset at having
to buy a large chunk of memory for my machine..
John
-- spike@world.std.com (Joe Ilacqua) (03/06/90)
In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes:
< Considering there are C compilers (well, atleast one) for the Apple II,
<how possible is it to write the "assembly only" sections of unix, and then
<compile the C sources for unix on a Apple II? I know it would require some
<of the heavy dute memory expansions that AE makes for the apple II,
<but still.
The big problem (TM) with porting UNIX (or any
multi-tasking/mulit-user OS) to Apple //s is that no Apple // has
memory management. This means all processes can write all of memory.
Instead of seeing "Segmentation fault (core dumped)", when you run a
program with a bug you'll just crash the system. This also means your
system will never be "secure", you would not want to you such a system
for a BBS.
This doesn't mean it can't be done. MINIX runs on 8086 based
IBM PCs, which don't have memory protection. MINIX, as some have
suggested in the past, might even be the place to start. But if it
was that easy...
Also keep in mind, that when people say "UNIX is highly
portable" they mean "UNIX is highly portable *for* an operating
system". There will be quiet a bit of effort in doing the port.
Someone is bound to say "UNIX ran on PDP-11s which had as
little a 64k". This is true, but it is like saying "Apple // DOS ran
in 16k". So what.
->Spike
--
"The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bpsstephens@latcs1.oz.au (Philip J Stephens) (03/06/90)
COOOOoooooOOOoooOOOKIE!!!! writes: > > Lately I've been wondering about a few things: > > Considering there are C compilers (well, at least one) for the Apple II, >how possible is it to write the "assembly only" sections of unix, and then >compile the C sources for unix on a Apple II? I know it would require some >of the heavy dute memory expansions that AE makes for the apple II, but still.. >I'm still using apple dos 3.3...I don't think I'd be terribly upset at having >to buy a large chunk of memory for my machine.. > >John Nice thought, but pretty much inpractical. First of all, remember that Unix is multitasking, whereas the Apple IIe is not! You'd have to modify the C sources quite drastically to get a single user version capable of running on an Apple. Either that, or get your hands on one that isn't multitasking. The same problems exist for implementing the virtual memory system, paging faults, disk I/O handling etc. Basically, what I'm trying to get at is you can't port over a standard version of Unix from a Pyramid, Mips or Vax. Someone has already mentioned the security aspects as well, which relates back to what ought to happen when a program crashes. Unix expects to regain control in situations like this, but on an Apple that is not always possible! Put simply, the 6502 (and the Apple in general) couldn't cope with anything but a diluted version of Unix; and in that case, you'd be better off re-writing the C sources yourself! Actually, writing a single user version of Unix from "scratch" wouldn't be that bad; if you're into that sort of thing...I would think that a basic version wouldn't be any more complex than DOS or ProDOS. I wouldn't mind attempting it if I had the time ;-)
pnakada@oracle.com (Paul Nakada) (03/06/90)
In article <7368@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: [ stuff deleted ] > Nice thought, but pretty much inpractical. > First of all, remember that Unix is multitasking, whereas the Apple IIe is > not! You'd have to modify the C sources quite drastically to get a single > user version capable of running on an Apple. Either that, or get your hands > on one that isn't multitasking. > The same problems exist for implementing the virtual memory system, paging > faults, disk I/O handling etc. Basically, what I'm trying to get at is you > can't port over a standard version of Unix from a Pyramid, Mips or Vax. > Someone has already mentioned the security aspects as well, which relates > back to what ought to happen when a program crashes. Unix expects to regain > control in situations like this, but on an Apple that is not always possible! > Put simply, the 6502 (and the Apple in general) couldn't cope with anything > but a diluted version of Unix; and in that case, you'd be better off re-writing > the C sources yourself! > Actually, writing a single user version of Unix from "scratch" wouldn't be > that bad; if you're into that sort of thing...I would think that a basic > version wouldn't be any more complex than DOS or ProDOS. I wouldn't mind > attempting it if I had the time ;-) Philip, your previous message contains many misconceptions that I would like to clear up. a) UNIX is a multiprocessing operating system (multitasking, whatever) b) There is no such animal as a single process (which I imagine you refer to as single user) UNIX operating system. UNIX is inherently multi processing, and thus multi user. c) The Apple //e is a computer. It is not an operating system. Therefore it should not be compared to an operating system. d) In any case, the Apple //e was not designed with a multi processing operating system in mind, but this does not rule out the implementation of one despite obvious obstacles (of which you point out many) -Paul Nakada pnakada@oracle.com
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/06/90)
ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes: > Considering there are C compilers (well, atleast one) for the Apple II, Well, most of them are pretty horrendous. I'd write an efficient compiler before even thinking about porting unix. Hell, I'd write an efficient compiler, period. The main reason the IIGS has miserable games support among the big name game companies is because there aren't any C compilers good enough to produce code that runs efficiently on it. It's a research problem; good compilers can be developed for anything but they take time. One of the best signs from Apple we could see is a PLEDGE TO FIX APW. Todd Whitesel toddpw @ tybalt.caltech.edu
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/07/90)
stephens@latcs1.oz.au (Philip J Stephens) writes: > First of all, remember that Unix is multitasking, whereas the Apple IIe is >not! Multitasking is provided BY unix. It is a pain to do without continuous interrupts, to be sure, but that is easy to provide. GEOS provides such a card when you buy the first package. Any Mockingboard or Mouse Card can be made to fire regularly timed interrupts which are essential for true pre- emptive multitasking. > You'd have to modify the C sources quite drastically to get a single >user version capable of running on an Apple. Either that, or get your hands >on one that isn't multitasking. I'd modify the sources period. There are lots of things about unix that we don't need. A version of the kernel that uses an interrupt source to provide multitasking shouldn't be that hard to do. Writing a decent C compiler for the Apple might be, but I maintain that it is not impossible, just time consuming. Compilers for the 68K stunk until Motorola poured lots of research into them. The same goes for the 80x86 or any CPU at all. 65xxx compilers simply haven't had the development man-hours that compilers for other CPUs have had. > The same problems exist for implementing the virtual memory system, paging >faults, disk I/O handling etc. Virtual memory would be a problem ONLY if you expect the compiler to be totally stupid. Boundary checking code could be added to compiled programs (as a debug option maybe) OR you could organize the data structures around the zero page indirect addressing scheme: (gasp) segment them. The main reason C compilers on the Apple stink is because they try to imitate a 68K which is IMHO neither necessary nor desirable. C itself looks like a 68K, but if you read the specs about pointers then it becomes obvious that the actual memory organization of the data is entirely the compiler's prerogative. Nobody seems to understand or exploit this. > Basically, what I'm trying to get at is you >can't port over a standard version of Unix from a Pyramid, Mips or Vax. I'll bet it could be done. Not to a bare //e, but to one with an interrupt source and decent C compiler. > Someone has already mentioned the security aspects as well, which relates >back to what ought to happen when a program crashes. Unix expects to regain >control in situations like this, but on an Apple that is not always possible! This is more the programmer's fault than anything else. The nice thing about hardware protection is that it gives you a safety net. The Mac and the Apple as of yet do not implement such safety nets so we must be more careful. >Put simply, the 6502 (and the Apple in general) couldn't cope with anything >but a diluted version of Unix; and in that case, you'd be better off re-writing >the C sources yourself! Currently, yes, but I still say that it is a software problem. The Amiga runs a version of unix without virtual memory. In unix's case I think you'd still be better off re-writing the sources. unix is not optimized for microcomputers, and an O/S as simple as unix but optimized for micros would be really nice. > Actually, writing a single user version of Unix from "scratch" wouldn't be >that bad; if you're into that sort of thing...I would think that a basic >version wouldn't be any more complex than DOS or ProDOS. I wouldn't mind >attempting it if I had the time ;-) Neither would most of us, we don't have the time either... I had some excellent ideas on how to write a great O/S for the Apple last year but found that my homework was more insistent on my time. :( Todd Whitesel toddpw @ tybalt.caltech.edu
certain@washington.cs.unc.edu (Andrew Certain) (03/07/90)
In article <7368@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: > First of all, remember that Unix is multitasking, whereas the Apple IIe is >not! You'd have to modify the C sources quite drastically to get a single >user version capable of running on an Apple. Either that, or get your hands >on one that isn't multitasking. I'm not sure that I believe that. The paging problem definitely exists, but isn't it a function of the OS, not the machine, that determines multitasking capabilites? The Mac under MacOS doesn't have true multitasking abilities, but it does under A/UX. I realize that we're talking about a much less powerful machine here, but I think that the posibility of multitasking isn't really a problem; however, like you said, paging is. I'm not really sure what you mean about disk I/O being a problem. If you mean that the Apple II doesn't have DMA, this is true, but neither does the Mac (which is why A/UX is painfully slow....well, that and many other reasons). I'm not doubting that UNIX under an Apple II or any 6502 machine would be fairly slow and poor, I'm just wondering if multitasking capabilities is a function of machine disign. Andrew Certain certain@cs.unc.edu
stephens@latcs1.oz.au (Philip J Stephens) (03/07/90)
Oh dear! I've been flamed for the misuse of terms!!! Let's see if we can't clear this up... In article <PNAKADA.90Mar6012126@pnakada.oracle.com>, pnakada@oracle.com (Paul Nakada) writes: > > b) There is no such animal as a single process (which I imagine you refer > to as single user) UNIX operating system. UNIX is inherently multi > processing, and thus multi user. Well, talking about Unix (TM), of course it is multi-user, multi-tasking etc. etc. That doesn't mean you can't create a stripped-down version of Unix which supports single processes. Naturally, it would no longer function in quite the same way as Unix does (in particular, you won't have parent and child processes), but you can certainly have a version that emulates the shell and passes control along to the program to be executed. It would simply become more like CP/M than Unix (TM). > c) The Apple //e is a computer. It is not an operating system. > Therefore it should not be compared to an operating system. I've now been picked up twice for making that comparison. I'm sorry that I didn't choose my words with more care. Maybe what I should have said is that the Apple //e is not the best computer to implement a multi-tasking operating system like Unix, simply because it doesn't provide an interrupt source. Sure, you can get an interrupt source by adding the right card, but a standard //e can't do it. You'd need to interpret your code, and that's slow. > d) In any case, the Apple //e was not designed with a multi processing > operating system in mind, but this does not rule out the > implementation of one despite obvious obstacles (of which you point > out many) OK, so it _could_ be done if someone decided to sit down and work very patiently through the problems. But the fact remains, the 6502 isn't a good processor for the job, and _alot_ of messy, sneaky tricks would be needed to get it to work. I wouldn't like to be the one who has to figure out the best way to implement virtual memory and paging (without exception conditions, you've got to simulate this in software) and so on. I'm sorry about this, but I hate messy code, that's all, which is why I said it in the first place. The basic point of the whole article was to say that it would be somewhat easier to write a single-user version of Unix from scratch, rather than to try and port bits of the real thing over to the //e. And if you wanted a multitasking version, you'd certainly be better off having an interrupt source from somewhere (so in that case, the original poster of this article might as well buy himself a clock card or mouse card or whatever, as well as the extra memory).
tvf@cci632.UUCP (Tom Frauenhofer) (03/07/90)
In article <7368@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: > First of all, remember that Unix is multitasking, whereas the Apple IIe is >not! You'd have to modify the C sources quite drastically to get a single Some points: 1) AT&T V6 Unix ran in 64K. Modern Unix's are notorious pigs, but it wasn't always that way. 2) You can do multitasking on just about any box. At worst, you have to have the tasks periodically invoke the kernel. You could hide this complication by having the compiler insert an occasional "call-scheduler" routine. If you have a timer interrupt, this requirement goes away - just have your scheduler wake up every interrupt. Once you have a mechanism to jump from task to task, the rest can be done (loading tasks, VM, etc.). The hardware can provide mechanisms to simplify (and speed up) these features, but just because it isn't there doesn't mean you can't do it. In fact, a friend of mine once showed me a "stupid" multi-tasker that ran on an apple II+. It was written in assembler, and I thought it was pretty hot (it only took up a couple of K of memory, too). I don't think he could run much pre-existing stuff, but he didn't care. If you want it, you can have it. Thomas V. Frauenhofer ...!rutgers!rochester!kodak!swamps!!frau!tvf *or* ...!uunet!atexnet!kodak!swamps!frau!tvf (tvf@frau, tvf@cci632) "What's a gourmand? I'll tell you, he's a P-I-G pig!" - Justin Wilson
toth@tellab5.tellabs.com (Joseph G. Toth Jr.) (03/07/90)
Just voicing my considerations regarding what I (and I feel most people)
would like to see from a UNIX(tm) type of environment on an Apple //;
1 - Multi-user capabilities is NOT a requirement..
It is my computer, and I have no intention of creating a BBS,
or allowing my kids on another terminal while I am working.
A 1Mhz clock rate is slow enough, and even with an accelerator
the overhead of multi-users is impractical.
2 - The ability to write scripts (cshell like, or others) that are
nestable, to perform complex functions based upon execution
of several executable processes.
2 - pipes for data transfer from one process to another.
3 - I/O re-direction of output to a file, the printer, etc.
4 - Multi-tasking is would be nice, but is not really necessary for an
implementation of pipes and I/O re-direction. These could be handled
by temporarily placing all output on a file (pipes place data on a
temporary file) and input to the next process that is loaded and
executed comes from either the keyboard or the temporary file, possibly
by having the system place the keyboard input in the same temporary
file that would have been read by the process from the pipe.
Nothing is impossible ( almost ;v) ), but is it practicle.
There alre already some shells (Davex, ProSel, ECP8, etc.) that provide
some of the capabilities of unix like shells with with some equivalent
command operations. Yet, none is a complete implementation; ECP8 does
some level of shell script operations but no piping; Davex has some
piping but lacks shell script executions; even HyperC-PROdos and Aztec C
execution shells provide limited shell script execution.
It seems that a combination of ECP8 and Davex could get very close to
allowing for a UNIX like envirnoment.
Now, aside from the problem of the implementation of the UNIX environment;
APPLICATION PROGRAMS.
APPLICATION PROGRAMS.
APPLICATION PROGRAMS.
All current applications should be executable from the unix environment,
however they would take over the machine (there goes multi-tasking).
There would have to be new compilers(et al) tailored to the UNIX environment.
Applications would have to be written to handle the piping and/or I/O
re-direction.
Is it a lot of work? YES, YES, YES
Is it worth it? Maybe, I don't really know.
Can it be done? As I said before... (anything can...)
w;
In article <1990Mar5.234421.396@world.std.com>, spike@world.std.com (Joe Ilacqua) writes:
> In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes:
[omitted] Question regarding feasibility (see above)
> The big problem (TM) with porting UNIX (or any
> multi-tasking/mulit-user OS) to Apple //s is that no Apple // has
> memory management. This means all processes can write all of memory.
> Instead of seeing "Segmentation fault (core dumped)", when you run a
--------------------------------
There are enough single-application programs that do this already.
I know, I know; Why add another layer of complexity to the existing problems..
> program with a bug you'll just crash the system. This also means your
> system will never be "secure", you would not want to you such a system
> for a BBS.
As I said before, how many people plan on generating a BBS just because
the UNIX might be capable of multi-user operation? How many people
plan on allowing multiple sessions on their Apple anyway (I know I don't)?
>
> This doesn't mean it can't be done. MINIX runs on 8086 based
> IBM PCs, which don't have memory protection. MINIX, as some have
> suggested in the past, might even be the place to start. But if it
> was that easy...
Nobody ever asked whether it was easy, the question was feasible.
>
> Also keep in mind, that when people say "UNIX is highly
> portable" they mean "UNIX is highly portable *for* an operating
> system". There will be quiet a bit of effort in doing the port.
The portability of UNIX really only exists in the user interface.
The portability of C code is also a question.
Does anybody who reads comp.sys.apple2 also read the newsgroups that
provide C source code files? Ever notice all the #ifdef's to determine
what code to use for which system and/or compiler?
Portability of UNIX and C is a joke..
And all I want is to have my Apple accept the UNIX form of commands and
provide the UNIX like piping and I/O redirection along with script execution.
Oh, yes; with the applications programs to go with them;
compilers, assemblers, linkers...
an editor - vi, emacs, etc.
cron - to go with my clock to execute jobs at certain times.
Does not even have to be multi-tasked. It could just run when
in the command parser environment and execute tasks in sequence
when no other tasks are active..
etc., etc., etc.
I know it's a pipe dream, totally impracticle, and probably not worth
even 1/1000000 th. the effort (conservative estimate); but, it would be nice.
> Someone is bound to say "UNIX ran on PDP-11s which had as
> little a 64k". This is true, but it is like saying "Apple // DOS ran
> in 16k". So what.
Yet, Why Not...
--
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr.
seldom understood. Don't FLAME on me, please. | uunet!tellab5!tothcertain@washington.cs.unc.edu (Andrew Certain) (03/08/90)
In article <1990Mar6.125046.2188@spectre.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: >Hell, I'd write an efficient compiler, period. The main reason the IIGS has >miserable games support among the big name game companies is because there >aren't any C compilers good enough to produce code that runs efficiently on >it. I thought that the reason the IIGS doesn't have much games support is because everything put out for the IIGS is pirated and distributed before the first copy is even sold. OK, maybe it's a few days after the first copy is sold. IIGS pirates are responsible for the lack of support because the pirating network is so substantial and well-organized. Apple isn't helping matters at all either by not supporting the machine (even though the user base for the Apple II is four thimes that of the Mac, according to the last figures I heard), but this isn't the only thing working against the IIGS. Andrew Certain certain@cs.unc.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/08/90)
In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes: >how possible is it to write the "assembly only" sections of unix, and then >compile the C sources for unix on a Apple II? I keep trying to tell you guys that it's not that simple! The assembly-language is just the part that is blatantly OBVIOUSLY machine-dependent. Most of the machine-architecture dependence of the UNIX kernel is actually reflected in C source code, not assembly language. Porting UNIX to another hardware platform is NOT repeat NOT a job for amateurs.
gwyn@smoke.BRL.MIL (Doug Gwyn) (03/08/90)
In article <7373@latcs1.oz.au> stephens@latcs1.oz.au (Philip J Stephens) writes: > Oh dear! I've been flamed for the misuse of terms!!! Let's see if we can't >clear this up... Nakada was exactly right. >That doesn't mean you can't create a stripped-down version of >Unix which supports single processes. The only thing that clears up is that you don't understand the essence of UNIX. A single-process operating system could by no valid stretch of the imagination be denoted a variant of "UNIX". Please pick some other name for what you propose, to avoid the contradiction in terms. In fact there are already several "UNIXy shell" environments available for the Apple //. If that is all you're after there is no need to do any operating system development.
toddpw@tybalt.caltech.edu (Todd P. Whitesel) (03/08/90)
stephens@latcs1.oz.au (Philip J Stephens) writes: >That doesn't mean you can't create a stripped-down version of >Unix which supports single processes. >It would simply >become more like CP/M than Unix (TM). What use is there for CP/M anymore... A single process unix is not unix, it's useless. > Maybe what I should have said is that the Apple //e is not the best computer >to implement a multi-tasking operating system like Unix, simply because it >doesn't provide an interrupt source. Sure, you can get an interrupt source >by adding the right card, but a standard //e can't do it. You'd need to >interpret your code, and that's slow. Interpret what? Who said anything about that? You can multitask without interrupts if you do it Multifinder style: All task switches occur during GetNextEvent or WaitNextEvent calls to the system (there may be more but it does work on a _cooperative_ basis, that is you must tell multifinder that you may be switched out and asking for an event does this because you are assumed to have processed all of yours before you call it). On the 6502, this could be done by the BRK instruction... Since it would also have the same hardware effect as an interrupt from a card then you could move to a real pre-emptive system with less trouble. Context switching would take some thinking out though. > OK, so it _could_ be done if someone decided to sit down and work very >patiently through the problems. But the fact remains, the 6502 isn't a good >processor for the job, and _alot_ of messy, sneaky tricks would be needed to >get it to work. I wouldn't like to be the one who has to figure out the >best way to implement virtual memory and paging (without exception conditions, >you've got to simulate this in software) and so on. I'm sorry about this, >but I hate messy code, that's all, which is why I said it in the first place. You're forgetting something which lots of people like to ignore: In real systems doing things in hardware usually means moving the mess into hardware unless somebody thinks of a clean way to implement it. Granted, it is much easier to implement the stuff in hardware, but I like the idea of figuring out a simple and efficient VM/paging system for the 6502 because it would encourage decent programming practices and might lead to the development of a great compiler and possibly an entire operating system. The 6502's virtue is that it is simple and cheap. The rest is up to us. Todd Whitesel toddpw @ tybalt.caltech.edu
) (03/08/90)
Instead of us learning to stop calling our idea of a unix-like OS that is
mono-processing, why don't you stop being so nit-picky and snotty about it..
you seem to be the only person who doens't know what someone means when they
use the terminology..and you actually do know what we mean..you just refuse
to accept it.
as for my message about just re-writting the assembly section..
before that you said nothing about the problem, because that was THE FIRST
POST ON THE SUBJECT IN HERE... you replied to the same article twice..
--
ccastjr@prism.gatech.edu
John Rudd (ex- kzin@ucscb)
The opinions expressed here-in are mine, and not those of my boss
(he has no opinions). Send all comments, flames, and complaints to /dev/null.jazzman@claris.com (Sydney R. Polk) (03/09/90)
From article <6673@hydra.gatech.EDU>, by ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!): > > Lately I've been wondering about a few things: > > Considering there are C compilers (well, atleast one) for the Apple II, > how possible is it to write the "assembly only" sections of unix, and then > compile the C sources for unix on a Apple II? I know it would require some > of the heavy dute memory expansions that AE makes for the apple II, but still.. > I'm still using apple dos 3.3...I don't think I'd be terribly upset at having > to buy a large chunk of memory for my machine.. > > John > > -- Unfortunately, it's not quite so simple. UNIX has it's own disk format. UNIX wants protected memory. UNIX would like hardware virtual memory. UNIX also would be much easier to run with linearly-addressable memory. One of my friends and I (Scott Lindsey) talked about this. Porting UNIX to the IIGS would be very difficult and time consuming; porting to the IIe would be virtually impossible. -- Syd Polk | Wherever you go, there you are. jazzman@claris.com | Let the music be your light. GO 'STROS! | These opinions are mine. Any resemblence to other GO RICE! | opinions, real or fictitious, is purely coincidence.
madd@world.std.com (jim frost) (03/09/90)
jazzman@claris.com (Sydney R. Polk) writes: >UNIX has it's own disk format. >UNIX wants protected memory. UNIX would like hardware virtual memory. >UNIX also would be much easier to run with linearly-addressable memory. >One of my friends and I (Scott Lindsey) talked about this. Porting UNIX >to the IIGS would be very difficult and time consuming; porting to the >IIe would be virtually impossible. UNIX is an interface, not an implementation. You could certainly implement a UNIX interface (primitive UNIX, anyway) with the Apple II hardware, although performance would be sub-optimal because of incredibly brain-damaged I/O hardware. You'd have to rewrite most of the kernel anyway so you might as well design it for the target system. jim frost saber software jimf@saber.com
don@brillig.umd.edu (Don Hopkins) (03/11/90)
In article <12316@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <6673@hydra.gatech.EDU> ccastjr@prism.gatech.EDU (COOOOoooooOOOoooOOOKIE!!!!) writes: >>how possible is it to write the "assembly only" sections of unix, and then >>compile the C sources for unix on a Apple II? > >I keep trying to tell you guys that it's not that simple! >The assembly-language is just the part that is blatantly >OBVIOUSLY machine-dependent. >Most of the machine-architecture dependence of the UNIX kernel >is actually reflected in C source code, not assembly language. >Porting UNIX to another hardware platform is NOT repeat NOT a >job for amateurs. Hi, Doug. Remember me from the days of info-apple? Anybody else from the old info-apple mailing list still around? I'm still using my Apple ][+, typing on it right now. 80 column videx card, full ascii keyboard, CPU in a wooden box I screwed together myself. Home brew Forth system with a hand written termulator. It does what I want very nicely -- it's a great terminal. But why would I ever want to run Unix on it??? Let's face it: Unix sucks. And there isn't a word strong enough to describe how bad it would be running on a 6502, even if it *were* possible. The Apple ][ is a neat little computer, but why would you want to eat it up running Unix? What's the point? A status symbol? Is there some particular Unix application you want to run? Port the application, you don't need the damn operating system. Look at all the Unix programs that have been ported to (eech) MS-DOS. What you need is a good 6502 C compiler, not a bloated operating system. I would like to have a good 6502 emulator that runs under Unix. A switch statement for all the opcodes would work fine, since any compiler worth using will compile a dense switch statement into a jump table. (Torek wrote a Z80 simulator a long time ago that worked that way.) I don't see why it should be specific to X though. (X sucks, too.) The hires graphics memory mapping would be a bitch. [but certainly more tractable than porting Unix to a 6502!] (BTW: Has anybody written an Apple hires <=> pbm image converter?) You would definitly not want to simulate disk I/O at the hardware level, with all the timing and nybble mashing involved, it would be *much* better to write a higher level ProDOS block driver that hooked into the simulator. -Don PS: Does anybody have a copy of the Apple contributed program library disk with the Lisp interpreter written in Basic?
rlw@ttardis.UUCP (Ron Wilson) (03/20/90)
In article <2218@tellab5.tellabs.com>, toth@tellab5.tellabs.com (Joseph G. Toth Jr.) writes: >The portability of UNIX really only exists in the user interface. >The portability of C code is also a question. >Does anybody who reads comp.sys.apple2 also read the newsgroups that >provide C source code files? Ever notice all the #ifdef's to determine >what code to use for which system and/or compiler? >Portability of UNIX and C is a joke.. As an experienced developper (and "porter") I can tell you that Unix and C are a heck of lot more portable than anything else. Unix runs on more different hardware than everything else combinded. The C language has been implemented on almost all new systems - with many "old" systems following suit. Granted that Unix and C portablity is overly touted - they ARE the most portable of general purpose systems and languages. True there are languages that are "totally" portable, but these languages are application specific - for example, Informix-SQL is the same on all combinations of OS and software that Informix, Inc supports - nice if that's all you need, but the real world demands more. Yes, porting C programs between systems - even 2 Unix systems - is very difficult. But it's a lot better than porting between 2 different languages, or worse, 2 different OS's.