Xref: utzoo comp.sys.amiga.tech:201 comp.sys.amiga:17361
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!eris!doug
From: doug@eris (Doug Merritt)
Newsgroups: comp.sys.amiga.tech,comp.sys.amiga
Subject: Re: AREXX the low/medium level standard - NEXT THE HIGH LEVEL
Message-ID: <8449@agate.BERKELEY.EDU>
Date: 7 Apr 88 23:15:27 GMT
References: <8647@eddie.MIT.EDU> <893@nuchat.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: doug@eris.UUCP (Doug Merritt)
Organization: University of California, Berkeley
Lines: 78
Keywords: K&R, nonstandard constructs, multi-char char constsants, hashing
Summary: Nonstandard C code

In article <893@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes:
>In article <8647@eddie.MIT.EDU>, gary@eddie.MIT.EDU (Gary Samad) writes:
>>
>> [...] IFF format structures, the parsing of which would dwarf the time
>> needed to do a FindPort! :-).
>
>I must take exception to this statement. I am the originator of the current
>IFF-based approach, and I'd like to point out that it does not require
>any parsing whatsoever. It has an array of tagged pointers which can be
> [...]
>			case 'REXX':

This is bad style...it is not guaranteed to work, according to K&R, and
certainly does *not* work with many C compilers. I don't know about Lattice
and Manx in particular, but even if they allow it now, they won't necessarily
allow it in the future. And there's a good chance that it won't work with
small model.  The standard way to specify long constants containing 4 ascii
characters is:
		(('R' << 24) | ('E' << 16) | ('X' << 8) | 'X')
or equivalently:
		#define	LONGCHRS(a,b,c,d) ((a<<24) | (b<<16) | (c<<8) | d)
		case LONGCHRS('R', 'E', 'X', 'X'):

This is still ugly, will still break *some* C compilers that can't quite
handle long constants in a switch, and furthermore counts on the compiler
being smart enough to create a hashed jump table; some C compilers are smart
enough to do that, some aren't. If they're not, then they'll produce code
that does a sequence of comparisons.  This point applies to the original
"case 'REXX':", too, btw.

Therefore the cleanest and fastest way (assuming that you're going to
check for more than a very few 4 byte constants) to do this is to create
a hashed array of the 4 byte strings, and do symbol table lookup,
returning a #defined constant that you then switch on:

#define	REXX	1	/* etc */
		switch(lookup(IffCode)) {
			case REXX:	[...]
			case ILBM:	[...]
		}

Note that the #defined constants will all be sequential integers, so
that the C compiler can create a very fast indexed jump table for this
(most C compilers have this optimization). Also note that it is possible,
if you work at it a little, to have it perform the lookup with a single
hash probe. The latter usually requires a fairly smart hash table
initializer, though, and generally people won't bother, so it could take
multiple probes. Note that the C compiler is highly unlikely to produce
code better than this with the original nonstandard construct "case 'REXX':",
because it's easier for people to optimize hashing than for a compiler to
do so.

Why do I nitpick? Because the rest of Peter's code was perfectly legitimate
C code (as opposed to psuedocode), which might lead people to say
"Hey, what a neat way to do that!", and we don't want to lead people
astray, now do we?

>Secondly, the HIGH-level IPC protocols for the machine already exist: namely
>files, pipes, and clipboards. Rather than create a whole new namespace, let's
>concentrate on tools to make that work better.

It's a very good idea to make good use of existing tools, but that does not
argue against using IPC. After all, IPC messages fit into the list
"files, pipes, and clipboards" as naturally as do the other members.

>Finally, as I said before... I'd go for REXX if there was a freely re-
>distributable dumb REXX server available. No, I'm not going to write
>one... I've got enough on my plate already.

Strongly agree. Any IPC standard therefore should not *count* on REXX.
But I think that's been pointed out several times before. Excuse me if
I've gotten confused about the current state of discussion.

	Doug Merritt		doug@mica.berkeley.edu (ucbvax!mica!doug)
			or	ucbvax!unisoft!certes!doug

	Doug Merritt		doug@mica.berkeley.edu (ucbvax!mica!doug)
			or	ucbvax!unisoft!certes!doug