6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Nov 22, 2024 8:58 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 2 of 2
  [ 26 posts ]  Go to page Previous  1, 2
  Previous topic | Next topic 
Author Message
whartung
PostPosted: Sun May 14, 2017 4:03 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
BigDumbDinosaur wrote:
Tor wrote:
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.
Top
 Profile  
Reply with quote  
barrym95838
PostPosted: Sun May 14, 2017 4:12 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
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.

Mike B.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sun May 14, 2017 4:37 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
barrym95838
PostPosted: Sun May 14, 2017 4:53 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GARTHWILSON wrote:
... I haven't looked into eForth, but hopefully it has a reasonably wealthy set of primitives.

Err ... keep hoping ...
Code:
: 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? :lol:

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.

Mike B.
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Sun May 14, 2017 5:31 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
:lol: 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...

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
barrym95838
PostPosted: Sun May 14, 2017 6:06 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GARTHWILSON wrote:
... 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) ...

Mike B.
Top
 Profile  
Reply with quote  
Tor
PostPosted: Sun May 14, 2017 7:04 am 
Offline

Joined: Sun Apr 10, 2011 8:29 am
Posts: 597
Location: Norway/Japan
whartung wrote:
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.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sun May 14, 2017 7:24 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
Tor wrote:
whartung wrote:
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sun May 14, 2017 7:27 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8506
Location: Midwestern USA
whartung wrote:
BigDumbDinosaur wrote:
Tor wrote:
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Mon Dec 28, 2020 10:35 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
GARTHWILSON wrote:
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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Top
 Profile  
Reply with quote  
BillG
PostPosted: Mon Dec 28, 2020 2:19 pm 
Offline

Joined: Thu Mar 12, 2020 10:04 pm
Posts: 704
Location: North Tejas
GARTHWILSON wrote:
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.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 2 of 2
  [ 26 posts ]  Go to page Previous  1, 2

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: Yuri and 31 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.