At last, someone deigned to make a reasonably coherent answer to my
questions.
Thanks Jonah
Continued thoughts interspersed below.
Jonah Thomas wrote:
> Charles Davis
gamewood.net> wrote:
> >>The idea was to take a 'chip(CPU)', write a ~200 byte 'FORTH
>>microkernal' in machine code, use that 'microkernal' to write (in
>>FORTH) the balance of the needed 'kernel' of an OS, use that to write
>>(in FORTH) the rest of the 'FORTH machine', and then you could take
>>off and solve, (in FORTH), whatever problem you had to start with.
>>
>>Today, I see little or no evidence of that method being applied to
>>todays CPUs. And I can't think of any valid reason why it SHOULDN't
>>be happening today.
>
>
> It could be done. If you don't mind 5-bit instructions etc you could do
> it with ColorForth. I've only heard about that getting ported to
> x86-type systems but it could be done on anything.
Well, actually FORTH itself would transport easily between ANY of the
CPUs available.
You skipped over my tale of my introduction to FORTH. I.. the moving Z80
FORTH to the MC6800 chip. Deciphering the Z80 code for the Microkernal,
and writing 6800 Machine code for the 6800 chip to use. AFTER the
microkernal, there was nothing to change. The rest of the FORTH OS/
Interpreter was already in existence, in a usable form (yeah, I had to
type it in, but there weren't any changes needed).
The ONLY thing that needs to change from system to system, [Basic, bare
bones], is the microkernal. To that FORTH Kernal, add whatever I/O for
your particular target hardware, and your done, as far as having an
operational system is concerned.
TO THIS, can be added more FORTH words, to make the resultant system
mimic ANY present OS.
There was a FORTH '87 as I remember, and it worked quite well. I never
heard of anyone actually doing (the mimic another OS) this, but it's
just some coding, so it's NOT in the impossible category.
>
> But here's why it doesn't get done more. One of the points of an OS,
> maybe the main point, is to provide an interface between applications
> and hardware. When you write an application you don't want to think
> about how to use a hundred different kinds of mass storage. You don't
> even want to think about how to use a hundred different kinds of
> printer. With a good OS, all that just works.
Right! This can be done with FORTH (Once, and then used with any other
'FORTH' system that happens to need those particular abilities).
> You tell the OS you want
> to use mass storage and it gives you a list of what's available. You
> tell the OS what to do and it handles the details.
>
You imply that this is not possible to do with an OS written in FORTH.
> You can do that with Forth. You can implement READ-FILE and WRITE-FILE
> for every kind of mass storage anybody might want to use your OS for.
> It's a lot of work.
>
> So you have everything running smoothly, and you wait for application
> writers to write polished apps to run on your OS,
Which one? If you write a "UNIX" OS (written in forth), won't they be
running UNIX compliant programs? With little or no thought to the
underlying machine gyrations.
An my point is, that IF the original FORTH aim is followed, the CPU of
your hardware no longer is significant. Write a 'microkernal', load the
FORTH "UNIX" knockoff, and you have a box running UNIX.
Can anyone see the advantages here? AMD chips, INTEL chips, Hitachi
chips, Motorola chips, etc.
NO re-writing of the OS, You do it once!!! [Well, actually, you do it,
and 'Bug-fix' as necessary till you get to a stable situation.]
The 'Modules for I/O' are done the same way. the only time you need to
change things, is for a NEW or changed type of I/O device.
Same for Storage, be it RAM, Disc, CDRAM, whatever.
That's for the UNIX contingent.
Any other Major (or Minor) OSs get handled the same way. Windows (in all
it's glorious variations, Linux (shouldn't be that much, LINUX after
all, is trying to clone UNIX.) OSX, now that one could get interesting,
there are PPC, and INTEL varieties of OSX.
> and they don't do it.
> Talk to a developer for desktops and ask him why not? He can get 99+%%
> coverage if he writes for Windows, Linux, and Macintosh. Your OS is very
> different from any of those so he can expect it will take an extra 33%%
> work compared to what he's already done for those three. Maybe your
> system is extra smooth and easy to use and it's really only an extra 3%%
> work. But why should he do an extra 3%% effort when there are no
> customers? And why should any customers use your OS when there are no
> applications?
>
> You might get somewhere with an OS for a dedicated system. The OS
> supports a few applications that work very very well, and the whole
> computer does just those jobs and no others. Customers buy the hardware
> and software together to solve particular problems.
Because that's what is available. Things would be different if there
wasn't the 'tight' coupling between Software & Hardware.
> Well, that approach
> works very well for small systems. It's tended to fail for things that
> are like desktop systems. For example ColdForth. They developed a
> complete Forth OS for a system using a Motorola chip, complete with HTTP
> etc. As near as I can tell, their applications were working fine,
> everything was working fine, but management decided to switch to
> uclinux. Maybe part of the reason was that the Forth OS was tied at its
> roots to that Motorola chip and it looked like too much effort to port
> it to other chips?
That's the problem!!! IF the FORTH was written 'properly', all it would
have taken would have been a 'new' kernal for the x86 family, and the
whole works would have worked quite happily on the many WINTEL boxes out
there.
They released the OS source code etc. I don't know of
> anyone who found much use for it. (I'd be glad to be corrected about any
> of this, I'm guessing beyond what I know in various ways.)
>
>
http://www.cvs.cx/uCForth.php
>
> In the early days of Windows, Forth, Inc built a process-control system
> that ran on top of MS-DOS.
I can understand that, it's easier to SELL something that has a bit of
'familiarity' to it.
> They had a sophisticated OO GUI system. They
> had a sophisticated multitasking system that let one PC plus a
> collection of microcontrollers handle a whole factory, with pretty
> graphics to make it obvious what was happening. As far as I know it
> worked as advertised. As far as I know there was no competing product
> that could compare to it at the time. It failed in the market. I don't
> know why and likely nobody who had the money to finance a definitive
> marketing study to find out why, cared to do so. Maybe there wasn't
> enough marketing money? The story I heard, from people who might
> possibly know, was that customers heard it ran under DOS and they didn't
> want it. They didn't want a PC dedicated to running their factory, they
> wanted a PC that would run their factory while they ran Word or Excel on
> it.
>
> People don't want a big complicated computer to run a few dedicated
> applications. So that approach will probably fail too. A simple
> dedicated systm doesn't need much of an OS. A complicated system needs
> many applications, and those applications exist for established OSes and
> not for yours.
>
Yeabut!!! The 'yours' you refer to can mimic ANY of the 'established OSs.
Chuck D.
