Re: 32 bit FORTH ??? Different tack! Jona

Charles Davis <cad@xxxxxxxxxxxx> wrote:
Jonah Thomas wrote:
Charles Davis <cad@xxxxxxxxxxxx> wrote:

Well, actually FORTH itself would transport easily between ANY of the
CPUs available.

Sure, that part gets done repeatedly. MPE and Forth, Inc both have Forth
versions that they transport among many mnay CPUs. Sometimes they don't
get around to porting to a particular CPU until they have a customer
who'll pay them to do it for him, since there's some effort involved and
that way they're guaranteed at least one sale. EForth gets ported
widely. Etc.

But when you have a Forth running on a CPU you haven't gotten very far
toward a modern OS.

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.

I thought there was a lot of potential for that when Mitch Bradley got a
whole lot of components people providing their stuff with Open Firmware.
They provided Forth code that said how to use their stuff, that could be
read by multiple OSes. I figured a Forth OS could figure out that stuff
as well as anything else. But the coalition of large companies that got
it working -- Sun, IBM, Apple -- one by one quit.

It isn't enough to have a little microkernel, you need code that can
handle all the hardware you're likely to see. That's what you're
competing against. You could possibly get by with a restricted range of
hardware. If you can handle one good graphics card and one cheap one,
one good sound card and one cheap one, one family of hard disks, one
CD-ROM, one DVD, one ethernet adapter, one of each kind of USB plug-in,
one printer, each major brand of game controller, and a big variety of
things I've overlooked, then you can handle the bare minimum people
expect of a modern OS -- for a limited set of hardware. People who
really want to use your system will buy the hardware it runs on. That's
what ColorForth has done, except they don't have nearly the whole list
and they depend on new ColorForth users who happen to have other
hardware to write their own drivers and publish them so the range of
acceptable hardware is slowly expanding.

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.

Here's the problem -- these other OSes are over-complicated and messy.
They were built by large teams who didn't communicate very well. All
their flaws add up to the main reason we want a better Forth OS -- you
could build an OS in Forth to say you'd done it, but the real point is
that you want something that's simple and workable, right? WHen you try
to emulate other OSes then you've taken on a new task that's at least as
complicated as the hardware problem. When you commit to emulating
Windows in Forth, carefully copying all the over-complex garbage, all
the mistakes -- so that the software that depends on them will run --
you are doing something that took Microsoft's many good programmers a
very long time. And your job is harder. A first-grade child can write
his name; how skilled do you have to be to forge his name so nobody can
tell he didn't write it himself?

And it's a moving target. As fast as you get it working, they'll be
releasing new versions that are different and subtly incompatible.

In the particular cases of Microsoft and Apple, you might be setting
yourself up for a lawsuit. Is it legal to emulate somebody else's
commercial OS? I don't know whether a look-and-feel suit would win, but
if they notice you you can expect a lawsuit you don't have the money to
fight.

It might work. There might be a valuable niche for a simple clean OS
that copies the complexities of one or more bad OSes so it can run their
many apps. It looks like a lot of work.

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.

If you want a UNIX Forth OS, maybe the better approach would be to start
with a Forth system running on Unix, and build bash in Forth. Also ash,
etc. When Forth is running all the unix shells then you have a start.
Then you start rewriting every C routine that users might call, in
Forth. Maybe you could write a C/C++ compiler that compiles to Forth,
that wouldn't actually be very hard to do although it's a big job to do
it efficiently. The more of Unix you get running in Forth, the closer
you are. It would be like remodeling a building as opposed to knocking
the whole thing down and starting fresh. Much easier to keep it
compliant when you change one thing at a time.

How much work does that look like? Does it look easier to estimate the
amount of work when you think of it that way as opposed to imagining
building everything from scratch?

And 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.

The chips are not really much problem. The last time I looked EForth had
32 routines written in assembly language and 5 system calls. It isn't
very hard to get eForth running on a new system that gives you those 5
system calls. But when you have it running you have a CLI system. No
mouse, no clicks, no DVD player. You get a standard input, an standard
character-based output, and a mass storage device. Chips are not the
problem.

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.

The ColorForth guys are doing that. They have a start. You could
build on what they're doing, if you want to.

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.

It would be easier if the hardware guys settled down to tight standards.
"I'm selling a hard drive. It's standard. It does nothing special or
different, it just does the same things faster and more reliably." But
hardware guys want their stuff to be better than standard, they each
hope to set the new standard. They don't want their products to be
commodities that compete only on quality and price, where price is very
easy to determine and quality is not.

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.

That's been a problem for people who tried to use ColdForth for other
things. But maybe their problem was that they had to maintain their own
device drivers for whatever devices they used. Plus they wound up with
dedicated hardware that only ran Forth, when management or users wanted
things that could also run lots of apps.

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.

The only explanation I've seen for its failure was that customers
(managers of large companies, mostly) didn't want DOS, they wanted
things that ran under Windows. It's very hard to persuade a lot of
customers to want something they ought to want, instead of what they do
want. If you want them as customers it may turn out easier to give them
what they want -- and arrange that you can turn it into what they need
when they see the need.

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.

If you want that, go for it! Most of the people who use Forth by choice
appreciate that they can get things done simply and easily. So they
don't have the patience to add tremendous complication so they can mimic
something that isn't nearly as good.

I could imagine it working, if you can do the work. There's a story
about Mitch Bradley that I probably have details wrong on, so I'll try
to skip the details. He was an engineer working for Sun, and they were
building a new component, a graphics processor or something. After hours
he went to the guys who were doing that and he built a Forth system to
interact with it, to help debug the hardware. There was a team that was
supposed to do that in C but they were behind schedule. His stuff
worked. The C guys fell more and more behind schedule, and when the
product shipped they shipped it with the drivers in Forth because the C
drivers weren't ready.

Another story -- Lotus-123 had a clone written in Forth, MVP-Planner.
The Forth system was easier to maintain, and when Lotus made upgrades
MVP-Planner had them working and available first. MVP-Planner didn't get
a whole lot of market share but its share was increasing fast enough
that Lotus noticed and got it shut down with a look-and-feel lawsuit.

So if you did somehow get a Linux clone working, and you tracked what
they wanted to put into the next version and you got it working before
anybody else did, they might possibly go with your version. You could
get the whole Linux community to switch to your kernel. Does it seem
plausible? No. Not the least bit. Even if your kernel is obviously
better in every way, would Linus agree to switch from what he's been
wrapping his mind around for years to something completely new? Not
plausible. And yet, it's the most likely approach I can imagine to
getting your hard work into many people's hands.
.

Relevant Pages

  • Re: What does (v) in menus stand for?
    ... chips rode piggy back, one chip on top of another and sharing the same ... and the correct fix was to cut it. ... problems getting this through my management, as I was a ... I managed, though a friend in the hardware department, to get ...
    (alt.usage.english)
  • Re: How to make Windows XP last for the next seven years
    ... having to spend the money to upgrade or get new hardware. ... down to removing and replacing chips on boards. ... capacitor that was leaking badly on the motherboard. ...
    (soc.retirement)
  • Re: How do you do this?
    ... not comparing like with like. ... whatever connects your chips, and the sleep to wake capabilities of ... whatever hardware there is there is. ... Defense? ...
    (comp.lang.forth)
  • Re: OT Dual core CPUs versus faster single core CPUs?
    ... The last one I can recall that was serious egg on face was the Intel F00F bug. ... CPUs are much more intensively simulated and individual key component blocks like multipliers and dividers are much more amenable to formal methods proof of correctness and reuse than generic freeform business software. ... I am truly amazed in the current generation of P4 chips that the register colouring and speculative execution doesn't cause more problems. ... The big difference is that committing to large scale bulk chip fabrication is *so* horrendously expensive that it doesn't happen until the thing simulates perfectly and tests out OK in prototype hardware against aggressive whitebox testers. ...
    (sci.electronics.design)
  • Re: Inspiron 1525 Hardware
    ... The 1.2.73 commit also added support for the 88E8048 and the 88E8070. ... The Linux folks refer to these chips as "FE+". ... CSet revisions worth looking at (clicking the revision string will take ... CSet 1.6247.96.1 -- fix for recv status hardware bug in FE+ chips ...
    (freebsd-stable)