[lebuffon]

This is interesting from the standpoint of the different mentality of Forth coders. If they really needed a fast removal of 4 stack items they would first code what you did.

Then after things were working they might replace droooop with something like this:

( Forth assembler psuedo-code follows)

     code droooop   sp 4 cells addi, next, endcode

One instruction to move the CPU stack pointer. Unthinkable to touch the stack pointer in most other environments but Toto we're not in Kansas. :)

*Next, is the traditional name of the "return to Forth function" in threaded Forth. A return instruction would be used in a native code Forth. Carnal knowledge of the internals is required and used by Forth coders.

[DonHopkins]

In a lot of FORTH implementations, constant numbers like 0, 1, -1 and others are hard coded, not just for speed but also for space: a call to a code word only takes one cell, instead of using two cells with a LIT [value].

Here's some Breshenham line code I first wrote in FORTH (Mitch Bradley's SunForth on a 68k Sun-2 with cg2 graphics board), then translated to 68k code (using the rpn FORTH assembler) -- the FORTH code is commented out before the corresponding assembly code:

https://donhopkins.com/home/archive/forth/cg/line.f

The cg2 board wasn't directly memory mapped -- it had a really weird way of selecting and accessing one row and one column at a time, which was kinda convenient for drawing lines and curves, and ropping blocks around, but nowhere as convenient as direct memory mapped access would have been.

https://donhopkins.com/home/archive/forth/cg/cg.f

I had to reverse engineer it from the map of the registers in this helpful include file:

https://donhopkins.com/home/archive/forth/cg/cg2reg.h

    * To save on virtual address space, we don't map the plane or pixel mode
    * memory (first two megabytes).  However, when calling mmap the user has
    * to add 2M to the desired offset anyway (goofy, huh?).

[kragen]

I never had a cgtwo, myself (because I never used a Sun2). Why do you suppose they used that weird "bank"-switching scheme? It occupied 4MiB of address space anyway!

Why were you in 640×480? I thought the cgtwo was 1152×900 like God intended, and that's what the .h says too.

Was the reason it was important to save virtual address space important that the 68010 ignored the upper 8 bits of virtual addresses? (Helllo, pointer typetag...)

The assembler looks pretty pleasant, though all the 68k operand size suf-, uh, prefixes make the code a bit LONGer than it could be. In gas I really miss having a macro system that can express nested control structures (so I guess I should quit my bitching and write one and use it). I suppose the tests for the IF and WHILE are limited to <, =, <>, >, 0<, 0>, and 0<>?

I'm curious what you think of my analogy upthread between stack-manipulation words and goto. Does it reflect your experience? I'd forgotten you'd done a bunch of Forth stuff.

[DonHopkins]

The wonderful thing about FORTH assemblers is that you have the full power of FORTH to write macros and code generation code with!

That particular assembler had structured control flow like if, while, etc.

It might have actually been a cgone, since the device name was /dev/cgone0. But the header file said cg2. Whatever it was, it was quite slow!

Years later, John Gilmore mentioned that he wrote that .h file with the C structures/unions that mapped out all the device registers.

I bought a copy of Aviator by Curt Priem and Bruce Factor, that ran on my SS2 pizzabox's GX "LEGO: Low End Graphics Option" SBus card (an 8 bit color + 2 bits monochrome overlay plane graphics accelerator):

https://techmonitor.ai/techonology/aviator_15_for_sun_networ...

>AVIATOR 1.5 FOR SUN NETWORKS OPENS UP GRAPHICS WORKSTATION GAMES MARKET. By CBR Staff Writer, 08 Jul 1991.

Not sure why the memory mapping was so weird -- but at least it wasn't as bizarre as the Apple ][! It did have some weird undocumented limitations, like you could only write to the colormap during vertical retrace (which I discovered the hard way -- it didn't seem to work for no apparent reason, except for the occasional times when it did kinda work).

Here's a reference to the cgone device that sounds about right:

http://ftp.uni-bayreuth.de/Digital/alphaserver/archive/magic...

    * SUN120  A Sun Microsystems workstation, model Sun2/120 with
    *   a separate colorboard (/dev/cgone0) and the
    *   Sun optical mouse.  Also works on some old Sun1s with
    *   the 'Sun2 brain transplant'.

http://www.sunhelp.org/faq/FrameBufferHistory.html

    Frame Buffer History Lesson 

    Last Updated: 24th November 1998

    cg1/bw1: device name : "/dev/cgoneX" "/dev/bwoneX"
    The color and monochrome framebuffer of sun100u. 
    It is not a crime not knowing anything about these. (and this was 7 years ago!)

[kragen]

Interesting, thanks!