The 'monitor' of Sun machines - the one you get to when you enter 'Stop A' - is written in Forth.
That "monitor" is a slow-moving bloated mess that made Jim Butterfield's Supermon for the PET/CBM computers look look like a race horse in comparison. I've had the dubious pleasure of mucking about in it. A classic example of poor programming language choice. Had it been written in assembly language or even K&R C it would have been several times faster.
I don't know about that. Hard to imagine anything someone does in a monitor being performance sensitive at all.
However, Suns when running in their default console mode were simply glacial, no matter what code you were running. I don't think their default console even felt as fast as a 9600 Baud terminal.
Fire up a graphical environment (X, Suntools), now you're cooking with gas. But if you using the out of the box console, then you're in for a slow day.
I have heard of Forth being called a lot of names, but "bloated" wasn't one of them, unless perhaps it was coded by someone who didn't understand "the proper Forth way" of doing things.
Did it run in some kind of emulation? My 3.2GHz dual-core Pentium 4 (yeah, I know it's old, but it should still perform!) brings old DOS software to a crawl when it's running the DOSBox emulator. My first 16MHz '286 was a lot faster, even though it had 1/200th of the clock speed, narrower buses, and a single core!
When Forth is slow, it's because someone wanted to go with a minimum of primitives, and write as much of the rest as possible in terms of those. I remember when there were these contemplate-your-navel discussions in Forth Dimensions magazine on how few primitives you could get away with, mostly with the excuse of portability of most of the kernel itself; but it got pretty ridiculous. They got it down to about 30, but imagine having to do a multiply in high-level with loops of shifts and ANDs and adds! Yeah, turtle speed (maybe not glacial, but very slow). Recently someone on another forum (IIRC) said you could get it down to about ten. I haven't looked into eForth, but hopefully it has a reasonably wealthy set of primitives.
: UM* ( u u -- ud )
0 SWAP ( u1 0 u2 ) 15
FOR DUP UM+ >R >R DUP UM+ R> + R>
IF >R OVER UM+ R> + THEN
NEXT ROT DROP ;
Does that answer your question, Garth?
My 65m32 DTC Forth codes UM* (and UM/MOD) as four-machine-instruction primitives, so it would be foolish for me to let something like that slide for very long, especially since the definition above is hard-coded for 16-bit cells.
They even made sure you have to re-format it to be able to read it. Thanks for the laugh! OTOH, depending on the processor, if each instruction there becomes only a single machine-language instruction...Hmmm...
... OTOH, depending on the processor, if each instruction there becomes only a single machine-language instruction...Hmmm...
My 65m32 isn't that good at Forth, but I think it does pretty well in that area for a "general purpose" processor. The following Forth primitives are at most one machine instruction plus a one instruction DTC NEXT:
doLIT doCOL EXIT branch EXECUTE @ R> R@ >R DROP DUP SWAP OVER 0< AND OR XOR NIP + NOT NEGATE 1+ CELL+ 1- 2+ 2- 2* CELLS 2/ ALIGNED
... and those are just the ones to which I've given the 65m32 treatment so far. It can effortlessly cruise beside a 6809 Forth kernel in machine instruction count, with cells that are twice as wide (lots of under-utilized op-word bits, though) ...
I don't know about that. Hard to imagine anything someone does in a monitor being performance sensitive at all.
However, Suns when running in their default console mode were simply glacial, no matter what code you were running. I don't think their default console even felt as fast as a 9600 Baud terminal.
Fire up a graphical environment (X, Suntools), now you're cooking with gas. But if you using the out of the box console, then you're in for a slow day.
Yes. When operating the Sun in console mode, the graphics card was programmed in the most basic way - and it was glacial. It's unlikely that had anything to do with what the monitor was written in. AIX P* boxes (PCI-based hw using sometimes standard PC boards) are the same btw - console text mode is very slow.
I don't know about that. Hard to imagine anything someone does in a monitor being performance sensitive at all.
However, Suns when running in their default console mode were simply glacial, no matter what code you were running. I don't think their default console even felt as fast as a 9600 Baud terminal.
Fire up a graphical environment (X, Suntools), now you're cooking with gas. But if you using the out of the box console, then you're in for a slow day.
Yes. When operating the Sun in console mode, the graphics card was programmed in the most basic way - and it was glacial. It's unlikely that had anything to do with what the monitor was written in. AIX P* boxes (PCI-based hw using sometimes standard PC boards) are the same btw - console text mode is very slow.
In contrast, the console on a couple of HP PA-RISC boxes I maintained in the 1990s was pretty snappy. They were really standalone terminals driven through a serial port at 115.2Kbps. There was a graphics card in one of the machines to which a VGA monitor could be attached, with a separate keyboard port that looked like the mini-DIN used with PC PS/2 keyboards, but never attached any hardware to give it a try.
The 'monitor' of Sun machines - the one you get to when you enter 'Stop A' - is written in Forth.
That "monitor" is a slow-moving bloated mess that made Jim Butterfield's Supermon for the PET/CBM computers look look like a race horse in comparison. I've had the dubious pleasure of mucking about in it. A classic example of poor programming language choice. Had it been written in assembly language or even K&R C it would have been several times faster.
I don't know about that. Hard to imagine anything someone does in a monitor being performance sensitive at all.
Memory searches, especially looking for patterns, are inherently compute-bound processes, so raw processing speed is very much important.
When Forth is slow, it's because someone wanted to go with a minimum of primitives, and write as much of the rest as possible in terms of those. I remember when there were these contemplate-your-navel discussions in Forth Dimensions magazine on how few primitives you could get away with, mostly with the excuse of portability of most of the kernel itself; but it got pretty ridiculous. They got it down to about 30, but imagine having to do a multiply in high-level with loops of shifts and ANDs and adds! Yeah, turtle speed (maybe not glacial, but very slow). Recently someone on another forum (IIRC) said you could get it down to about ten. I haven't looked into eForth, but hopefully it has a reasonably wealthy set of primitives.
I'm on the ForthHub discussion group (although I don't think I've ever posted). Posts get sent out by email. I just got this one which carries my point above to an amusing extreme:
Quote:
Hi folks,
I was curious how many low level words do you need to build forth. So I took sod32 by Lennart Benschop which uses 32 low-level words and started to redefine low level words via other low-level words. The whole process can be seen here. At the end of the day I managed to reduce low-level words to 7 primitives: nop, nand, !, @, um+, special, lit. Inner interpreter has additional logic for 'exit' and 'call'. I was running tester.fr to ensure all words behave as expected and also used run time to track performance. My final implementation runs 708 times slower than original sod32. This whole effort hardly can be used in practice, but it was a fun little project. I wonder if we really need 3 primitives to access memory: @, ! and lit? Please let me know if there is any trick I can use to reduce this.
Thanks.
Kirill.
(emphasis added)
I might add that in high-end optimizing STC Forth compilers, the matter of primitives and secondaries seems to get lost, as everything gets compiled to very efficient machine language. No one has written such a compiler for 65xx though, for multiple reasons.
Did it run in some kind of emulation? My 3.2GHz dual-core Pentium 4 (yeah, I know it's old, but it should still perform!) brings old DOS software to a crawl when it's running the DOSBox emulator. My first 16MHz '286 was a lot faster, even though it had 1/200th of the clock speed, narrower buses, and a single core!
Depending on what software you run, hitting CTRL+F12 like a dozen times makes it much more usable.
