I know almost nothing about ASM, but I am curious to know if it is
possible to write a GUI MS Windows-like operating system entirely in
ASM? This means no use of high level languages, just pure ASM code. If
it is possible, would the ASM written OS be blazing fast compared to MS
Windows?

Thanks.

On Wed, 29 Jun 2005 19:00:35 +0000 (UTC)
"Doug"  <spamtrap@crayne.org> wrote:

:If
:it is possible, would the ASM written OS be blazing fast compared to MS
:Windows?

It is certainly possible to write such an operating system in assembly
language, and doing so would provide some opportunities for an experienced
programmer to improve the speed of some functions. However, there is no
guarantee that machine language code generated from ASM will be any faster
than machine language code generated by a compiler.

-- Chuck

In article <1120066304.993611.200620@g43g2000cwa.googlegroups.com>,
Doug <spamtrap@crayne.org> wrote:
>I know almost nothing about ASM, but I am curious to know if it is
>possible to write a GUI MS Windows-like operating system entirely in
>ASM? This means no use of high level languages, just pure ASM code. 

Of course it's possible.  It may not be very practical, but it's possible.

Remember that everything written in a high level language ultimately gets
turned into assembly langauge (in general) before it's executed.

>If it is possible, would the ASM written OS be blazing fast compared to MS
>Windows?

That depends on the skill of the person doing the programming.  I'm sure
Microsoft cranks up the optimizations on their compilers when building code
for their OS, so it may be hard to optimize some of their code better in
assembler.  I expect there are pieces of the OS that could be sped up with
a creative approach to some of the low-level routines in Windows.

Does that answer your questions?

On Wed, 29 Jun 2005 19:00:35 +0000 (UTC), "Doug"
<spamtrap@crayne.org> wrote:

>I know almost nothing about ASM, but I am curious to know if it is
>possible to write a GUI MS Windows-like operating system entirely in
>ASM? This means no use of high level languages, just pure ASM code. If
>it is possible, would the ASM written OS be blazing fast compared to MS
>Windows?

It's been done: http://www.menuetos.org/

-- 
ArarghMail506 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

Doug wrote:
> I know almost nothing about ASM, but I am curious to know if it is
> possible to write a GUI MS Windows-like operating system entirely in
> ASM? This means no use of high level languages, just pure ASM code. If
> it is possible, would the ASM written OS be blazing fast compared to
> MS Windows?

MenuetOS is just such a project. IIRC it has a GUI, and it is written in 
pure assembly. It also has a network stack and some other useful bits. I 
have never gotten it to boot; your mileage may vary.

As to whether or not it would be "blazing fast", I think that depends more 
on the assembly language programmer than anything else. It is urban myth 
that you can write code in assembly and it will automatically outperform 
HLLs, specifically C/C++. Compiler writers are by nature good assembly 
language programmers, and that means that the compiler will almost always 
produce faster code than inexperienced assembly language programmers. Even 
for experienced assembly language programmers it *can* be difficult to beat 
the compiler. It depends on the problem.

The main difference is that most assembly language programmers have a fair 
idea of how expensive different operations are. HLLs tend to obscure that. 
However, usually code written in an HLL has better structure since the 
programmer is concentrating on the high level design and not the low level 
implementation.

-Matt 

Patrick Klos wrote:
> In article <1120066304.993611.200620@g43g2000cwa.googlegroups.com>,
> Doug <spamtrap@crayne.org> wrote:
> >I know almost nothing about ASM, but I am curious to know if it is
> >possible to write a GUI MS Windows-like operating system entirely in
> >ASM? This means no use of high level languages, just pure ASM code.
>
> Of course it's possible.  It may not be very practical, but it's possible.

It's not only possible, it's been done.  Geoworks (later Geoworks
Ensemble, later New Deal Office, now Breadbox Ensemble) was a GUI
environment that ran on my 512K 8088 in 1989 and was able to multitask
well in low memory situations due to the very fine granularity of code
objects the system was designed in.  The GUI was based on Motif and had
detachable menus and other Motif-isms.  The entire display system was
based on scalable vectors, very similar to Display Postscript (and was
quite snappy, not at all slow like you'd expect).  Coupled with a
smarter-than-average virtual memory system, it was truly impressive
even on modest hardware.  All written in pure ASM, unless I'm
misremembering something.

Microsoft monopolistic tactics killed it, but I won't get into that
flamewar (in this forum :-).

Doug asked:
| I know almost nothing about ASM, but I am curious to know if it is
| possible to write a GUI MS Windows-like operating system entirely in
| ASM? This means no use of high level languages, just pure ASM code. If
| it is possible, would the ASM written OS be blazing fast compared to MS
| Windows?

Yes, my KESYS core (128 KB incl. native graphics) is written on a 
machine code monitor (KESYS-HEXEDIT & HEX_WORK85) in pure hexadecimal.

It cannot be direct compared to M$ as it is more technical oriented,
it got functions and applications which you wont find on any windoze
and opposite, but a user may not see much difference, except:
screen layout, no useless messages and no double-clicky and friends.

__
wolfgang kern 
  How fast and short could windoze be
  if everyone would think like me.
http://web.utanet.at/schw1285/KESYS/index.htm   

"Doug"  <spamtrap@crayne.org> wrote:
>
>I know almost nothing about ASM, but I am curious to know if it is
>possible to write a GUI MS Windows-like operating system entirely in
>ASM? This means no use of high level languages, just pure ASM code. If
>it is possible, would the ASM written OS be blazing fast compared to MS
>Windows?

Windows was written in assembler.  It wasn't until Windows 95 that the
16-bit version contained a meaningful percentage of C.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

wolfgang kern wrote:

<snip>
> It cannot be direct compared to M$
<snip>

You might want to consider changing your signature then.  Might I
suggest:
"How fast and short could windoze be if it did a lot less computation
and contained a lot less functionality"...not as pithy but quite
accurate I think! ;-)

> wolfgang kern
>   How fast and short could windoze be
>   if everyone would think like me.
> http://web.utanet.at/schw1285/KESYS/index.htm

Also, I don't know if you're aware of this but you've got your keyboard
region setting set to Zealot, where the digraphs MS and ws map to M$
and ze, respectively.

Yes it can be done,
for example it has been done by me also ;) in SolarOS

You can have source,screenshots, etc here:
http://www.hostileencounter.com/os_main.html
http://www.oby.ro/os/index.html

However ASM is "just" a programming language as any other.
With the wrong algorithms it can be as slow as any other language.

Because it is the closest to the hardware ASM has the potential to be
very fast if used by a master... But the simple fact to use ASM does
NOT guarantee great speed. ASM also requires more patience, knowledge
and understanding than other programming languages.

Reagrds,
Bogdan Ontanu

Charles A. Crayne wrote:
> On Wed, 29 Jun 2005 19:00:35 +0000 (UTC)
> "Doug"  <spamtrap@crayne.org> wrote:
>
> :If
> :it is possible, would the ASM written OS be blazing fast compared to MS
> :Windows?
>
> It is certainly possible to write such an operating system in assembly
> language, and doing so would provide some opportunities for an experienced
> programmer to improve the speed of some functions. However, there is no
> guarantee that machine language code generated from ASM will be any faster
> than machine language code generated by a compiler.
> 
> -- Chuck

"who knows?" <spamtrap@crayne.org> wrote:
 
| <snip>
| > It cannot be direct compared to M$
| <snip>
| 
| You might want to consider changing your signature then.  Might I
| suggest:
| "How fast and short could windoze be if it did a lot less computation
| and contained a lot less functionality"...not as pithy but quite
| accurate I think! ;-)


I think about a translation hint for the unaware:
 
"How fast and short could windoze be: 
 if it avoided all the HLL-detours
 if it renounced of the paranoid protection
 if it contained only needed functions
 if it gave up on down to the museum backwards compatibility 
 if M$ wont force hardware manufacturers to hide their internals
 if ... (a very long list indeed)
 
| > wolfgang kern
| >   How fast and short could windoze be
| >   if everyone would think like me.
| > http://web.utanet.at/schw1285/KESYS/index.htm
 
| Also, I don't know if you're aware of this but you've got your keyboard
| region setting set to Zealot, where the digraphs MS and ws map to M$
| and ze, respectively.

Nothing wrong with my keyboard :)

__
wolfgang
 

"Charles A. Crayne" schrieb:
> "Doug"  <spamtrap@crayne.org> wrote:

> :If
> :it is possible, would the ASM written OS be blazing fast compared to MS
> :Windows?

> It is certainly possible to write such an operating system in assembly
> language, and doing so would provide some opportunities for an experienced
> programmer to improve the speed of some functions. However, there is no
> guarantee that machine language code generated from ASM will be any faster
> than machine language code generated by a compiler.

Isn't there a further language inside the cpu (called microcode)? 
Why not write direct in this language?

lin8080 wrote:
[...]
> Isn't there a further language inside the cpu (called microcode)?
> Why not write direct in this language?

Because you can't. Intel and AMD do not document their microcode, AFAIK.

Furthermore, microcode is very limited. While some decades ago it was trendy 
to design microprocessors around microcode, it no longer is. If I understand 
correctly, microcode is only used on x86 CPUs to implement the complex pmode 
logic (interrupts, instructions like arpl, task switching, etc.). If my 
understanding is correct, then it isn't possible to write microcode programs 
like you would write assembly programs.

-Matt 

On Sat, 2 Jul 2005 09:14:35 +0000 (UTC), lin8080
<spamtrap@crayne.org> wrote:

>Isn't there a further language inside the cpu (called microcode)? 
>Why not write direct in this language?

The only time I saw that done was a major mistake. The NCR 9300
minicomputer was built from bit slice processors, I think it was the
Signetics 2900 set. They used Forth for the microcode, then built an
OS and a complete hospital management system on it, all in Forth and
linked directly into the microcode. There was only one man in the
world that understood how it worked, and he was not an employee of
NCR. He had them over a barrel and knew it. It cost them US$10,000.00
per day for his time, with a minimum of three days per visit. That was
in 1983 dollars, by the way. They only sold a handful, but supported
it for over ten years. Poor management like that is one of the major
reasons they're not around any more.

Yes, I worked for them from '79 to '85, writing tech manuals for the
first two years and QA for the rest. So I have one of their 100th
anniversary pins. Fortunately, testing that abomination was not one of
my projects. That consultant got paid more for one visit than my
annual salary.

Bob McConnell
N2SPP

On Sat, 2 Jul 2005 09:14:35 +0000 (UTC), lin8080
<spamtrap@crayne.org> wrote:

<snip>
>Isn't there a further language inside the cpu (called microcode)? 
Yes. But only used for some instructions.

>Why not write direct in this language?
Well, for Intel and Amd processors, there is no easy (if any) way that
I know of to get the processor to use it.  Furthermore, AFAIK, the
language details are not documented.

There have been processors in the past that had that feature.  The
HP-2100 was one, a 16 bit mini.  (I think that was the model, I can't
find the reference manual, just now.)  

Also, some Burroughs (probably spelled wrong) processors had loadable
microcode that was specific to a language processor.
-- 
ArarghMail507 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the garbage from the reply address.

Yes, the Burroughs had microcode that implemented some instructions such as 
'search'.

The Sperry 1100/60 was mostly microcode driven.  The instruction set was the 
same as the 1108 from decades before, but additional instructions were 
enabled by the field engineers who just loaded a floppy into their 
maintenance console.  Since processor technology had improved, I understood 
that the three processors that made up each logical processor used an 
instruction set that was quite different from the assembler code we had. 
They used the three processors to detect failures.  Every processor did 
every instruction and if the results differed, the one that did match the 
other two was disabled and the operator notified.

I don't expect any of this to be in PC in my lifetime.  We need to keep the 
speed up so each new processor becomes available to run our code and not 
check on another processor.  If we needed that type of failure detection we 
would be using ECC memory instead of the standard non-parity DIMMs.

<spamtrap@crayne.org> wrote in message 
news:vhncc1l17q4v8kajgrs4o914a3erred3vi@4ax.com...
> On Sat, 2 Jul 2005 09:14:35 +0000 (UTC), lin8080
> <spamtrap@crayne.org> wrote:
>
> <snip>
>>Isn't there a further language inside the cpu (called microcode)?
> Yes. But only used for some instructions.
>
>>Why not write direct in this language?
> Well, for Intel and Amd processors, there is no easy (if any) way that
> I know of to get the processor to use it.  Furthermore, AFAIK, the
> language details are not documented.
>
> There have been processors in the past that had that feature.  The
> HP-2100 was one, a 16 bit mini.  (I think that was the model, I can't
> find the reference manual, just now.)
>
> Also, some Burroughs (probably spelled wrong) processors had loadable
> microcode that was specific to a language processor.
> -- 
> ArarghMail507 at [drop the 'http://www.' from ->] http://www.arargh.com
> BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
>
> To reply by email, remove the garbage from the reply address.
> 

"Matt" <spamtrap@crayne.org> schreef in bericht 
news:Krzxe.176125$IO.139048@tornado.tampabay.rr.com...
> lin8080 wrote:
> [...]
>> Isn't there a further language inside the cpu (called microcode)?
>> Why not write direct in this language?
>
> Because you can't. Intel and AMD do not document their microcode, AFAIK.
>
> Furthermore, microcode is very limited. While some decades ago it was 
> trendy to design microprocessors around microcode, it no longer is. If I 
> understand correctly, microcode is only used on x86 CPUs to implement the 
> complex pmode logic (interrupts, instructions like arpl, task switching, 
> etc.). If my understanding is correct, then it isn't possible to write 
> microcode programs like you would write assembly programs.

Suppose one would take such an old processor (one designed around 
microcode), how would You provide it with the microcode? Mnemonics are 
translated by the assembler in bitpatterns which are put in ROM or RAM and 
through the bus the processor loads them (I am not trying to teach You a 
lesson because I know You know this, I am saying it to make clear what I 
really mean with my question). But where and in what form would You put the 
microcode to get it executed?

Yours sincerely,
Rene 

On Sat, 2 Jul 2005 18:54:00 +0000 (UTC)
"Rene"  <spamtrap@crayne.org> wrote:

:But where and in what form would You put the 
:microcode to get it executed?

You would load it into the chip itself, similar to the way in which one
upgrades a BIOS chip.

-- Chuck

Bob McConnell  <spamtrap@crayne.org> wrote:
>
>The only time I saw that done was a major mistake. The NCR 9300
>minicomputer was built from bit slice processors, I think it was the
>Signetics 2900 set. They used Forth for the microcode, then built an
>OS and a complete hospital management system on it, all in Forth and
>linked directly into the microcode. There was only one man in the
>world that understood how it worked, and he was not an employee of
>NCR. He had them over a barrel and knew it. It cost them US$10,000.00
>per day for his time, with a minimum of three days per visit. That was
>in 1983 dollars, by the way. They only sold a handful, but supported
>it for over ten years. Poor management like that is one of the major
>reasons they're not around any more.

NCR is still around.  They have simply changed their business model from
the "old school", in which you actually produced and sold products, to the
"new school", in which you earn money by having a team of lawyers extort
money out of "old school" companies by threatening lawsuits from your
useless patent portfolio.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

"Charles A. Crayne" schrieb:
> "Rene"  <spamtrap@crayne.org> wrote:

> :But where and in what form would You put the
> :microcode to get it executed?

> You would load it into the chip itself, similar to the way in which one
> upgrades a BIOS chip.

Thanks for input.
If it is not the same processor (or chip), maybe the code piece can be
write into the memory (RAM) and read out by the processor very fast.
This should be a not so chip specific way, but makes no sense, while
code is passing the processor twice or more. Another cpu is in newer
graphic cards (fast transfer rate) but this is another story (more
hidden parts i guess and no way to reach mem without cpu). 

So sad no microcode is available. But don't worry, I read about the
cell-chip (nintendo3?) and now my thoughts go around how to keep this
monster busy ... (�hm - redo strategic parts on my x86 homePC)

lin

lin8080 wrote:
[...]
> If it is not the same processor (or chip), maybe the code piece can be
> write into the memory (RAM) and read out by the processor very fast.
> This should be a not so chip specific way, but makes no sense, while
> code is passing the processor twice or more. Another cpu is in newer
> graphic cards (fast transfer rate) but this is another story (more
> hidden parts i guess and no way to reach mem without cpu).

The CPU does have caches. Modern desktop x86 chips seem to be equipped with 
512K to 1MB. The more-expensive Xeons come with even more.

> So sad no microcode is available. But don't worry, I read about the
> cell-chip (nintendo3?) and now my thoughts go around how to keep this
> monster busy ... (�hm - redo strategic parts on my x86 homePC)

Assuming your code can be parallelized to the extent that Cell requires it 
to be. From what I have read, Cell is more comparable to GPUs than to CPUs. 
Some applications fit nicely into that niche. Many, particularly the 
applications used in SPECint tests, do not. Already there are boards on the 
market with architectures remarkably similar to Cell's that you can buy and 
install in a PCI slot to use for similar purposes.

-Matt 

David J. Craig wrote:
[...]
> I don't expect any of this to be in PC in my lifetime.  We need to
> keep the speed up so each new processor becomes available to run our
> code and not check on another processor.  If we needed that type of
> failure detection we would be using ECC memory instead of the
> standard non-parity DIMMs.

Most boards support ECC memory. However, as ECC memory is more expensive, 
most people don't buy it. The (highly vendor-dependent) machine check 
feature of modern x86 CPUs can report ECC errors in both main memory and the 
CPU caches/registers.

Also, for trivia's sake, Intel made an ICE for the Pentium which ran the 
same computations and compared the results. It wasn't intended for the same 
purposes and so did not have the same level of fault-tolerance -- an error 
was detectable but not correctable. I would imagine it was also very slow.

-Matt 

On Wed, 29 Jun 2005 19:00:35, "Doug"  <spamtrap@crayne.org> wrote:

> I know almost nothing about ASM, but I am curious to know if it is possible to write a GUI MS Windows-like operating system entirely in ASM? 

Yes.  

Just replace programmers trained to write in high-level languages
with programmers trained to think in high-level languages and to write
in ASM.

Add lots of programmers, if you want to meet the manager's deadlines,
because writing in ASM is just time-consuming work.

> If it is possible, would the ASM written OS be blazing fast compared to MS Windows?

Why not do a simulation -- take a Corvette on a day-time test-drive 
through the parking-lot
of any shopping mall on the last Saturday before Christmas -- the 
Corvette is 
blazingly-fast, but 90% of its horsepower is "wasted" 99% of the time.

Similarly, if the CPU-meter within Windows is showing 5% to 20% of 
maximum,
most of the time, then the CPU has lots of untapped capacity that the 
Windows GUI 
did not need to use.

On Sun, 3 Jul 2005 03:21:48 +0000 (UTC)
spamtrap@crayne.org (Melvin Klassen) wrote:

:Add lots of programmers, if you want to meet the manager's deadlines,
:because writing in ASM is just time-consuming work.

Not nearly as much as one might think -- if the development environment has
been properly set up.

-- Chuck

Charles A. Crayne wrote:
> On Sun, 3 Jul 2005 03:21:48 +0000 (UTC)
> spamtrap@crayne.org (Melvin Klassen) wrote:
>
>> Add lots of programmers, if you want to meet the manager's deadlines,
>> because writing in ASM is just time-consuming work.
>
> Not nearly as much as one might think -- if the development
> environment has been properly set up.

Development environment or not it is still substantially trickier to write 
x86 code since you are limited to 7 registers and only 4 callee-preserve 
registers. On nearly all non-trivial pieces of code I find myself having run 
out of registers for variables (especially those callee-preserve registers) 
and I am left with 2 choices: either blindly spill things to the stack or 
perform intelligent register allocation. The first results in code that is 
much worse than the compiler's code, and the second is extremely 
time-consuming and error-prone.

On a machine with more registers, perhaps even x86-64 with its meager 16, I 
would agree that the difference is not so large.

-Matt 

"Charles A. Crayne" <spamtrap@crayne.org> schreef in bericht 
news:20050702123706.59861c72@heimdall.crayne.org...
> On Sat, 2 Jul 2005 18:54:00 +0000 (UTC)
> "Rene"  <spamtrap@crayne.org> wrote:
>
> :But where and in what form would You put the
> :microcode to get it executed?
>
> You would load it into the chip itself, similar to the way in which one
> upgrades a BIOS chip.

Thank You, now I understand it.

Sincerely,
Rene 

Bob McConnell wrote:
> On Sat, 2 Jul 2005 09:14:35 +0000 (UTC), lin8080
> <spamtrap@crayne.org> wrote:
>
> >Isn't there a further language inside the cpu (called microcode)?
> >Why not write direct in this language?
>
> The only time I saw that done was a major mistake. The NCR 9300
> minicomputer was built from bit slice processors, I think it was the
> Signetics 2900 set. They used Forth for the microcode, then built an
> OS and a complete hospital management system on it, all in Forth and
> linked directly into the microcode. There was only one man in the
> world that understood how it worked, and he was not an employee of
> NCR. He had them over a barrel and knew it. It cost them US$10,000.00
> per day for his time, with a minimum of three days per visit. That was
> in 1983 dollars, by the way. They only sold a handful, but supported
> it for over ten years. Poor management like that is one of the major
> reasons they're not around any more.

Some folks on comp.lang.forth called my attention to this.  Although I
wasn't directly involved with that project, I do know some things about
Forth on the 9300.  This was a system that was developed primarily by
Greg Bailey, of Athena Programming, for NCR.  Greg actually developed a
Forth for the microcode in the 9300; he did this fixed-price for a sum
that represented less than a tenth of what NCR had paid one of their
experts to do the microcode supporting their OS, and the result ran
vastly faster than NCR's OS.

There were a lot more of the hospital systems installed than the
program
implies, though -- I knew of a dozen or so in California alone, and NCR
had a whole division supporting the product line.  Overall, the
hospital application (which Greg did not write) was written and
supported by a group at NCR in Ithaca, NY, some members of which are
also friends of mine.

I don't think the Forth-in-microcode was used universally by NCR on the
9300, only the hospital system (as far as I know).  A conventional OS
was written using whatever their original microcode expert developed.

I can't imagine who this expensive consultant might be.  Greg is fairly
pricy, but not like that (and an excellent value, too, given what he
can do in a day!).  And there are quite a few people who could have
worked competantly on the hospital system (including the folks at
Ithaca, FORTH, Inc., and most any other competant Forth programmer with
system-level experience). I've seen the code (we considered using the
9300 for a couple of projects), and it's quite readable for anyone
familiar with Forth.  That was most assuredly NOT true, of course, of
the microcode as it was written to support NCR's OS -- it really WAS
arcane witchcraft!

Cheers,
Elizabeth

==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

On Tue, 5 Jul 2005 03:32:19 +0000 (UTC), spamtrap@crayne.org wrote:

>Bob McConnell wrote:
>> On Sat, 2 Jul 2005 09:14:35 +0000 (UTC), lin8080
>> <spamtrap@crayne.org> wrote:
>>
>> >Isn't there a further language inside the cpu (called microcode)?
>> >Why not write direct in this language?
>>
>> The only time I saw that done was a major mistake. The NCR 9300
>> minicomputer was built from bit slice processors, I think it was the
>> Signetics 2900 set. They used Forth for the microcode, then built an
>> OS and a complete hospital management system on it, all in Forth and
>> linked directly into the microcode. There was only one man in the
>> world that understood how it worked, and he was not an employee of
>> NCR. He had them over a barrel and knew it. It cost them US$10,000.00
>> per day for his time, with a minimum of three days per visit. That was
>> in 1983 dollars, by the way. They only sold a handful, but supported
>> it for over ten years. Poor management like that is one of the major
>> reasons they're not around any more.
>
>Some folks on comp.lang.forth called my attention to this.  Although I
>wasn't directly involved with that project, I do know some things about
>Forth on the 9300.  This was a system that was developed primarily by
>Greg Bailey, of Athena Programming, for NCR.  Greg actually developed a
>Forth for the microcode in the 9300; he did this fixed-price for a sum
>that represented less than a tenth of what NCR had paid one of their
>experts to do the microcode supporting their OS, and the result ran
>vastly faster than NCR's OS.
>
>There were a lot more of the hospital systems installed than the
>program
>implies, though -- I knew of a dozen or so in California alone, and NCR
>had a whole division supporting the product line.  Overall, the
>hospital application (which Greg did not write) was written and
>supported by a group at NCR in Ithaca, NY, some members of which are
>also friends of mine.
>
>I don't think the Forth-in-microcode was used universally by NCR on the
>9300, only the hospital system (as far as I know).  A conventional OS
>was written using whatever their original microcode expert developed.
>
>I can't imagine who this expensive consultant might be.  Greg is fairly
>pricy, but not like that (and an excellent value, too, given what he
>can do in a day!).  And there are quite a few people who could have
>worked competantly on the hospital system (including the folks at
>Ithaca, FORTH, Inc., and most any other competant Forth programmer with
>system-level experience). I've seen the code (we considered using the
>9300 for a couple of projects), and it's quite readable for anyone
>familiar with Forth.  That was most assuredly NOT true, of course, of
>the microcode as it was written to support NCR's OS -- it really WAS
>arcane witchcraft!
>
>Cheers,
>Elizabeth
>
>==================================================
>Elizabeth D. Rather   (US & Canada)   800-55-FORTH
>FORTH Inc.                         +1 310-491-3356
>5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
>Hawthorne, CA 90250
>http://www.forth.com
>
>"Forth-based products and Services for real-time
>applications since 1973."
>==================================================

Hi Elizabeth,

If the division you mention was Ithaca Terminals and Printers, after
'88 that support consisted of less than a dozen people, including the
editors for the manuals. It was the only non printer group left in
Ithaca after 1987. I worked in the Ithaca plant writing tech manuals
from Oct '79 to '81, then in Product Evaluation until I was laid off
in September '85, along with 170 others. There were 1800 there when I
started, but they let me go as the plant passed down through 900
employees. By '89 it was down to 275, including ANSWER printer
manufacturing and the handful of people left on the hospital project.
They were back up to 325 by the time the printer operation was sold to
Axiom.

After the Banker fiasco in '82, most printer design and manufacturing
was moved to Japan, and the 7900 series of terminals was outsourced.
The 7920 was sent to the Clemson plant and finally became the PC-IV,
just weeks before IBM announced their AT.

Greg may have been the consultant I was told about. The prices were
quoted to me by one of the support reps still working there in after
Axiom bought the plant, but since moved on. I lost track of him after
his email address disappeared under a head crash, but I trust RADAR to
not lead me astray.

I'm curious about who you know from there. I only worked on printers
and terminals, other than drafting the test plans for the graphics
display subsystem in the Banker system. Dave Bulatek now has an office
next to mine, and he sees Andy Kobziar and a couple of others
regularly. Chris Ball was working for Ithaca Peripherals, but I
haven't seen him for more than a couple of years. Tom Sims has an
EMI/RFI consulting practice near Ithaca we use occasionally, and Bob
Nagle has retired into carving Norwegian caricatures. Other than that,
I haven't seen anyone for years.

I can be reached through either rmcconne at lightlink or rvm at cbord.
Add the usual dot com to your choice.

I'm not a Forth person. That always looked too much like a write only
language to me. I even have to leave good commentary in my C code to
be able to read it six months later.

Bob McConnell
N2SPP

Andy Kobziar is the one I know best.  Please send him my regards.  Andy
represented NCR on the ANS Forth Technical Committee, of which I was
the chair, from 1986 through 1993.

I find it very hard to believe Greg ever charged that much.  He did
quite a lot of work for NCR, but he also worked for us some in that
time frame, and as I said earlier, he was so productive we found him
quite cost-effective.  And I've never known him to charge a rate
anything like that!  My nominee would be whoever wrote the
"conventional" microcode.

Forth does look a little strange if you're not used to it, but it's
pretty easy to learn.  Of course, I advocate leaving good commentary in
any code in any language!

Cheers,
Elizabeth
erather {at} forth {dot} com

Rene wrote:

> Suppose one would take such an old processor (one designed around 
> microcode), how would You provide it with the microcode? Mnemonics are 
> translated by the assembler in bitpatterns which are put in ROM or RAM and 
> through the bus the processor loads them (I am not trying to teach You a 
> lesson because I know You know this, I am saying it to make clear what I 
> really mean with my question). But where and in what form would You put the 
> microcode to get it executed?
> 
> Yours sincerely,
> Rene 
> 

Most of the microcoded processors held their microcode in ROM on chip,
and it was entirely unaccessable.

> Also, I don't know if you're aware of this but you've got your keyboard
> region setting set to Zealot, where the digraphs MS and ws map to M$
> and ze, respectively.

Mocking a convicted monopoly-abuser does not make one a zealot.