Objects in C; NEON; Letters

By Jörg Langowski, MacTutor Editorial Board

“Objects in C; NEON; Letters”

Since the C++ compiler that I’m supposed to use for this column still hasn’t arrived here (but will for the next column, as I was just assured), I take the opportunity to talk about some other OOP- and Forth-related things that I’ve come across lately, and to share with you some of my mailbox’ contents. First, some readers seemed to be quite worried that the Forth column was going to die completely.

One response came from Conrad Weyns, who works as a video sound technician in Oslo:

“Dear Sir, or Jørg if I may say so,

The August issue of MacTutor just arrived. Oh, new cover colorful what no Forth corner this time oh well, it’s happened before. Jörg’s Folder Code optimization, no more Forth column, WHAT!

Better late than never as the saying goes. Here’s one anyhow that has been using Forth, especially Mach on the Macintosh, ever since its introduction in the market for a mere 49 US dollars, and has been an eager reader of your column.

So to keep this short, please accept a thousand thanks for all your past “Mach2-Forth” contributions in MacTutor and don’t hesitate to convey this to the MacTutor readers.”

Christian Teuscher, a musician in Vienna writes:

“As one could learn from the last MacTutor, the Forth tutorials are dead and gone [Not quite - they have just taken a break / JL].That’s a shame, since it’s just that language that I have problems with.

I am a composer and - lacking alternatives - am using an object-oriented MIDI extension to Mach2 called HMSL. This has been written by Phil Burk (Mills College), with whom I’ve just started an ambitious project: Network Composing. -

The idea is that several composers write small modules that communicate with each other inside the HMSL shell - thus, the eternal metamorphosis. Would you know musicians who also use computers in their work?”

[I know two musicians personally who use the Mac in their work, not only applying programs that exist but also writing their own MIDI code. One is Philippe Chatiliez, sysop of the MIDI section of the Calvacom bulletin board and the French contact person for PAN (Performing Artists’ network). His address is the same as that of Solidarsoft - no surprise since he founded it: 66 bd Exelmans, F-75016 Paris, France. The other is Benoit Widemann, creator of the shareware DA editor Joliwrite.

I even received a letter which complained about the demise of the BASIC column, probably because it was me who broke the bad news. Michael Zuteck, a wind energy consultant in Kernah, Texas wrote:

“Hold on here, maybe it is just a question of who are vocal readers. Have followed your message of BASIC faithfully, with particular interest in performance benchmarks. I note the plan to cut back such coverage with great alarm (pg 94 August 89). It is a major part of why I subscribe.

You see, I write a lot of special purpose engineering programs. Very simple I/O, lots of calcs. There are lots of languages that can handle this, but BASIC has the fundamental advantage of running on a low cost portable as its resident language. Lots of times that’s a lot more important than speed or esoteric programming capabilities useful in large scale application development. Lots of machines & lots of people can run the code if it’s in BASIC, and while it has its limits, it remains truly the “language for the rest of us”. Please hang on in covering it.”

Let me emphasize again that the Forth column hasn’t died, there will only be some alteration between a Forth/assembly column and an object-oriented C column. I can’t speak for Dave Kelly, but I’d be surprised if BASIC would die out completely; it is also up to you to send in articles with interesting stuff - in Forth, in BASIC - that you have programmed or come across otherwise.

We might get some new object-oriented surprises in Forth soon. NEON seems still to have its niche, if I can believe my Bitnet mail.

NEON - still alive ???

The following discussion could be read some weeks ago on the Forth Interest Group International mailing list on Bitnet:

From: Bob Loewenstein

<rfl@ODDJOB.UCHICAGO.EDU>

Subject: oo forths

Speaking of object oriented forths...NEON is still alive and well on my Mac II. There are a few basic additions to the kernel (like a methods stack using another 68000 address register). The rest is high level additions to forth. The additional stack allows the use of local and named input variables. Multiple cfa words can also be defined . Early and late binding are supported. Instantiation in the dictionary or on the heap.

--------------

From: Nicholas Geovanis 312-996-0590

<UWC6NTG@UICVMC>

Subject: NEON

Bob Loewenstein mentioned NEON, which I read an article on a few years back, but filed and forgot about. Can anyone point me to a comprehensive source describing syntax and philosophy? How about commercial and PD interpreters?

Much Obliged,

Nick Geovanis - UWC6NTG at UICVMC.EDU

SysProg - Univ. of Ill. Admin. Comp. Ctr. Chicago

--------------

From: Kevin Berg

<microsoft!kevinbe@UUNET.UU.NET>

Subject: Re: oo forths

...(deleted -jl)...

The author of Neon went on to make Actor, an Object Oriented environment for MS-Windows. Is Kriya Systems still supporting Neon? There were many bugs reported in the early versions, which turned me away. I’m interested in this if the support has been decent.

It might also be interesting for you to share some of the OO implementations that you find useful, or cumbersome, via example. I’m sure many others would be interested.

- k

--------------

From: Bob Loewenstein

<rfl@ODDJOB.UCHICAGO.EDU>

Subject: NEON

Kriya is no longer supporting Neon, as far as I know. But we at U of C are, having been involved with Chuck Duff and its development. Kriya updated Neon up to version 2.0 which supported HFS, floating point, and assembly; in addition, most of the bugs were fixed.

Since then we have created interfaces to color quickdraw and have developed image processing software on a Mac II. The original 2.0 works on a MacII and SE030, and under multifinder; I think this is testimony to Chuck and the others that created this environment when 512 macs were just becoming widespread (prior to Mac+’s).

Even though Kriya no longer supports it, it is easy to massage it to keep current on newer macs and ROMS. It’s simple to write interfaces to new calls in the toolkit of the Mac. I look at Neon as a great enhancement to Forth. Forths have a tradition of being supported by its users, and Neon is not unique in this.

kevinbe@microsoft.UUCP (Kevin Berg) writes:

> It might also be interesting for you to share some of

> the OO implementations that you find useful, or

> cumbersome, via example. I’m sure many others

> would be interested.

One example is color image support on a Mac II. If anyone has tried this after reading the sections in IM V5, you know what I mean. A lot of things need to be done for each image and window that is created. By making an image class and a colorWindow class, with the appropriate pixmaps and colortables as instance variables created when needed, the whole operations becomes quite easy. Multiple images are just multiple instances of the same class, which can be targeted to any colorWindow object. I don’t have to write specialized code for each image, nor do I have to worry about creating the windowPalette, the colorTable, etc. each time I create another image. In fact, it works so nicely, I really have forgotten how things work since it’s now part of my system.

I don’t have to handle button hits, menu hits, event queues...they are all handled by the Neon system. It’s relatively simply to affect global changes deep in the system by small inheritances later on.

Nicholas Geovanis writes:

> but filed and forgot about. Can anyone point me to a

> comprehensive source describing syntax and

> philosophy? How about commercial and PD

> interpreters?

Kurt Schmucker’s book on object oriented languages and the Mac had a section on Neon. It was prior to version 2.0. As I remember, he rated it the fastest of all the implementations. This is partly due to the fact that early binding is the default, with an option to late bind if one wants.

We have thought of porting Neon to other machines. It doesn’t seem to be that difficult, just requiring some time to do the work. Most of the code is at high level. If anyone is interested, they could write me directly, or call.

Bob Loewenstein

--------------

From: Bob Loewenstein

<rfl@kepler.yerkes.uchicago.edu>

Subject: Re: NEON

A small group of us here at UC Astronomy is continuing to use Neon and supporting it for our own use, and for a couple of groups at Goddard Spaceflight Center. Actually, very little support has been necessary. As I remember, the only support for the MacII was to change the toolbox list of traps to incorporate the new calls in the new ROMs. I don’t think that we ever had an initial problem of just getting the original NEON.COM to run on a MacII. There is some funny bug in the Install module that restricts the kernel to run on either a mac+ or a macII, but not necessarily both. It’s sort of a hit and miss procedure to get a kernel that works on both; it has to do with the dictionary size you pick.

Other than that, I’ve fixed a number of small bugs and made some useful changes. The only modification to make it run under multifinder was to increase the suggested memory size using get info from the finder. I changed the number from 384 to 1000 and it runs. If the apple menu gets too many entries (either due to suitcase or many applications running) it no longer becomes possible to click out of Neon into another application. A quick fix is to instantiate another applemen of greater length, fill it with dodsk, and reread the menu file in and everything works fine.

All in all, I was very surprised at how robust Neon has been. I have talked to Kriya recently trying to get Neon placed in the public domain...they seem very reticent to do this even though they have no plans of reviving it. They are afraid of some old unresolved litigation and don’t want to jeopardize their wealth. They promised to get back to me soon (maybe this week).

If you want some help bringing up your 2.0 version on the macII, I might be able to diagnose what’s going on. As I said, I just put it on and it worked. I do remember that my stack size is over 8k. dictionary size was about 200k.

Here is a list of modifications I have made from the original 2.0:

MODIFICATIONS TO NEON

New methods:

Control setTitle( addr len --), getTitle( -- addr len),

getnew(id wind --), enable:, disable:

box size in y decreased by 3 pixels

Menu mitem

handle unlock(-), lock(-), movehi(-), locked?(-b)

event zoombox supported

file flushVol (-)

proc removed nop

base - extend is faster, >uc fixed

nucleus ic! fixed, (.stack) protected,

cmove replaced with trap

fargs fixed ;m

fltmem fixed 2dup

indlg draw: fwind removed from each dlg

added remembers current cursor

tools supports macII-increased table lengths and

collision table cell size

decompile fixed float bug, .num shows signs, contains

your own methods

qprint shows revision date

date init: removed-no longer needed -

must get: then print:

port kill:

timer clear:

alert! returns 0 1 2 3 for which button was pressed

hfs? now works

nucleus has fwind not visible, but the word neon performs a show: fwind. If you don’t want fwind around at startup, don’t say a thing to it.

npath now a vect ‘c your own pathfinding word

support for popUp and Hiearchical menus

ability to auto search method names in source and create new decomp.BIN

for multifinder, load this to allow moving from neon to another application:

35 menu applemen

‘c dodsk fill: applemen

nmenu

-bob

Fortran Feedback

The August column also gave rise to some interesting comments from Language Systems Corporation:

“Dear Jörg,

We just received the August MacTutor with your very interesting column about code optimization. Since we released Version 1.2.1 of Language Systems FORTRAN in January, we have been working on new features - including an optimizer - that will be added in Version 2.0, which is planned for release this fall.

Our strategy with Language Systems FORTRAN up to now has been to generate clean, accurate code that gives correct answers and runs as fast as possible without changing the original FORTRAN program in any significant way. The heavy-duty optimization will appear for the first time this fall. We do still have a few things to fix (like the extra EXT.L instruction you discovered), and we appreciate your helping us finding them.

Starting with Version 2.0, Language Systems FORTRAN will offer several additional formal optimizations of the FORTRAN code. The text of your article mentioned that the FORTRAN-generated code calculates the subscript for c(i,k) every time it appears in the FORTRAN source. That is not unusual for a compiler without formal optimization passes, and in fact if you examine the listings on page 98 from the MPW Pascal and MPW C compilers, you will see that they also generate code to calculate the subscript twice. The optimization that compiler writers use to remove unnecessary identical instructions is called “common subexpression elimination”, and Version 2.0 of our FORTRAN will have it.

We have found that in many cases it is easy for us humans to spot a way that compiler-generated code could be improved, but extremely difficult to encode all the logic to enable a compiler to identify the opportunity for improvement and still perform all the safety checks to make sure the change will not backfire. For example, if two variables A and B are equivalenced or in COMMON, storing a value into B can change the value of A because they may occupy the same memory location. Once we start doing things to the code written by the FORTRAN programmer (like removing parts of it or changing the order of execution) we have to do a comprehensive set of safety checks to make sure that the compiler’s surgery on the code does not introduce any bugs, and we are busy installing those safety checks in our optimizer and testing the results now.

You may have noticed the way Language Systems FORTRAN calculates array indexes looks a little unusual when compared to MPW Pascal and MPW C. That’s because Language Systems FORTRAN is the only one of the three compilers that allows arrays and array indexes to exceed 32K in size.

We appreciate your interest in Language Systems FORTRAN , and I welcome any additional suggestions of ways we can improve.

Sincerely,

[I know that looking at a compiler’s assembly output and showing up the obvious blunders is always a little unfair. If one really needs optimum speed, one can always code in assembler from scratch, or straighten out the compiler’s output. I am aware that your addressing of arrays bigger than 32K words creates some problems in indexing. However, even large arrays can be addressed PC-relative through 32-bit indexed addressing modes both on the 68000 and the 68020, one doesn’t need to compute the address explicitly. On the 68020, one can even include scaling in the indexing instruction. Smarter indexing would probably be one of the major performance factors in any code that does a lot of matrix computation (thus most scientific/engineering calculations).

Oh, I see

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

Those of you who want to get object-oriented in C without learning a whole new language should take a serious look at a shareware package created by John Wainwright. It is called OIC, the version that I downloaded is 1.02, and it consists of a set of object-oriented extensions that should work with any C compiler (it comes as a Think C project, and that’s how I tested it). The package is available on major bulletin boards, such as Compuserve or GEnie (MacPro libraries #1474), or in France on Calvacom.

OIC passes messages to objects using ‘generic functions’. This is a mechanism similar to that used in object-oriented Lisp. An example: to create a new instance of the class window, you would write:

/* 1 */

 object w; /* in the declaration part */
  
 w = New(Window, BOUNDS, &bounds,
     TITLE, “\pMacTutor”,
     KIND, (long)rDocProc,
     END);

The message ‘New’ creates a new instance of a class. Here it is simply a function with the class name and a list of properties of the object as arguments. BOUNDS, TITLE, and KIND are keywords for certain parameters of the window, followed by their values.

For objects of other types, New might take different arguments; the first argument is always the class name, followed by a variable number of parameters for initialization.

How does OIC’s message dispatching mechanism work? When you call a generic function - like New in the example - the OOP system looks at the first argument and scans the methods available for that class. It then passes control to the actual method function, which is implemented in the class declaration. The method function receives three arguments: the object that uses the method, a pointer to the object’s instance variable structure, and a pointer to the argument list that follow the class name in the generic function call. For instance, in the example you would define:

/* 2 */

static object
_new(self, w, wa)
 object self;
 register window_i  *w;
 register keyword_args  wa;
{
 w->window = 
 NewWindow(NULL, key_arg(wa, BOUNDS, NULL),
 key_arg(wa, TITLE, “Untitled”),
 -1,
 (int)key_arg(wa, KIND, 1L),
 -1L, 1, self);
 return Super(self, END);
}

key_arg is a function which searches the argument list (pointed to by wa) for a keyword and returns the value following the keyword, or a default if the keyword is not contained in the list.

The newly defined class and its methods must be made publicly known. This is done through an initialization function such as

/* 3 */

InitWindowClass()
{
 Window = NewClass(sizeof(window_i), 0, 
 “Window”, List, END);
 AddMethods(Window,
 newGeneric,     _new,
 drawGeneric,  _draw,
 repListGeneric, _repList,
 END);
}

NewClass (iv, cv, name, super1, super2, , END) is a function that defines a new class with instance variable size iv and class variable size cv. super1, super2, , END is a zero-terminated list of arguments which contains the ancestors of the new class. This implies, of course, that multiple inheritance is supported.

In the example, Window inherits from List. This is done so that one can associate a contents list with the window; objects to be drawn. The Draw method for Window scans this list and calls the Draw method for each member (see listing).

AddMethods is a function that adds the class methods to the generic function dispatch tables. After the AddMethods call, the method will be ‘known’, and when the generic function (say, Draw) is called with an object of type Window, its _draw method will be invoked.

You see that OIC does everything at run time; messages are always late-bound. In the C-’generic function’ approach, this cannot be done otherwise, because there is no way for the C compiler to know the type of an object at compile time. Remember that in OIC any object x is declared by just writing

object x;

and only later, in the course of the program, the type of the object is determined by calling

x = New(Class,arg1,arg2, );

The type of the object x may change any time; at compile time we don’t know what method will be used when we write draw(x).

Late binding is not too bad, however; OIC uses a way of method dispatching that avoids too much overhead. The advantage of the generic function approach is that almost anything may be changed at run time. I haven’t tried this out, but since the class Window is defined by assigning the result of the NewClass call to the variable window, this assignment might be changed at run time.

The whole idea of OIC is very Lisp-like, and the author in fact plans to add a set of Lisp classes to support more advanced list processing concepts.

I’m not going into more details here; you may get an impression of how to program in OIC from the listing, where I printed excerpts of the author’s example window class together with my own FillRRect declaration, and a main program that makes use of those classes. The fully built test application will be on the source code disk; as of this writing, I’m not sure whether we can distribute the complete shareware OIC system, but if you have problems downloading it from one of the mentioned bulletin boards, write me at

LANGOWSKI@FREMBL51.BITNET

and I’ll help you. I think OIC is a powerful system whose use should be encouraged.

Next time - cross my fingers - C++.

Listing: Examples of OIC code
/* Objects-In-C test program
 * based on the test program by J. Wainwright © 1988
 * J. Langowski/MacTutor 1989 */
 
#include “oic.h”
#include “generics.h”

enum { TITLE = 1, BOUNDS, KIND };
extern class Window; 

main()
{
 object rect1;
 object box1, box2;
 register int  i;
 extern  class  Coord, Box, Window, FillRRect;
 object w;
 static Rect   bounds = {100, 100, 350, 350};
 GenericTable  *gen;

 MaxApplZone();
 
 /*  initialize OIC. */
 InitOIC();
 InitSysClasses();
 InitTestClasses();
 InitNameClasses();

 /* Box is another class not shown here, which defines 
 a rectangle */
 print((box1 = New(Box, 100.0, 100.0, 
 200.0, 200.0)));
 print((rect1 = New(FillRRect, 50.0, 50.0, 
 150.0, 150.0, 4.0, 4.0, gray)));
 
 w = New(Window, BOUNDS, &bounds, TITLE, “\pMacTutor”,
     KIND, (long)rDocProc, END);
 
 add(w, box1, New(Box, 150.0, 150.0, 190.0, 190.0), rect1, END);
 draw(w);
 print(w);
 
 box2 = New(Box, 10.0, 10.0, 20.0, 20.0);
 offset(box2, 1.0, 4.0);
 add(w, box2, END);
 draw(w);
 print(w);
 
 /* check the “cantDo”, “CanYouDo” mechanism
  *
  * the first two methods are known to w,
 the last one isn’t */

 gprintf(screen, “%s append\n”, CanYouDo(w,
 appendGeneric) ? “I can do “ : “I can’t do “);
 gprintf(screen, “%s equal\n”, CanYouDo(w, 
 equalGeneric) ? “I can do “ : “I can’t do “);
 gprintf(screen, “%s softBind\n”, CanYouDo(w, 
 softBindGeneric) ? “I can do “ : “I can’t do “);
 
 /* print the list of generics */
 gprintf(screen, “the generics ...\n\n”);
 for (i = 0, gen = generics; gen != NULL; 
 i++, gen = gen->gen_next)
   gprintf(screen, “%d: %s()\n”, i, GenericName(gen));
 
 gprintf(screen, “all done\n”);
}

InitTestClasses()
{
 InitCoordClass();
 InitBoxClass();
 InitWindowClass();
 InitFillRRect();
}

/* FillRoundRect class
 * © Joerg Langowski/MacTutor 1989  */
#include “oic.h”
#include “generics.h”

class  FillRRect;

struct FillRRect_i /* FillRRect instance structure */
{
 Rect myRect;
 int    ovalWidth,ovalHeight;
 Pattern*pat;
};
typedef struct FillRRect_i FillRRect_i;

/* ---------- FillRRect Instance methods ---------- */
static object
_new(self, r, ra)
 object self;
 FillRRect_i*r;
 struct {
 double top;
 double left;
 double bottom;
 double right;
 double ovalWidth;
 double ovalHeight;
 Pattern  *pat;
 } *ra;
{
 r->myRect.top = ra->top;
 r->myRect.left = ra->left;
 r->myRect.bottom = ra->bottom;
 r->myRect.right = ra->right;
 r->ovalWidth = ra->ovalWidth;
 r->ovalHeight = ra->ovalHeight;
 r->pat = ra->pat;
 return Super(self);
}

static
_draw(self, r)
 object self;
 FillRRect_i*r;
{
 FillRoundRect (&r->myRect, r->ovalWidth,r->ovalHeight,
r->pat);
}

/* ---------- Init the FillRRect class -------------- */
InitFillRRect()
{
 FillRRect = NewClass(sizeof(FillRRect_i), 0, “FillRRect”, END);
 AddMethods(FillRRect,
 newGeneric,   _new,
 drawGeneric, _draw,
 END);
}