From @mail.uunet.ca:beejay@micor Thu Dec 10 01:59:41 1992
Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629)
	  on Thu, 10 Dec 92 01:59:39 -0600 id AA02556 with SMTP 
Received: from mail.uunet.ca (uunet.ca) by calvin.sfasu.EDU with SMTP (5.59/25-eef)
	id AA12972; Thu, 10 Dec 92 01:54:55 CST
Return-Path: <@mail.uunet.ca:beejay@micor>
Received: from ocunix by mail.uunet.ca with UUCP id <9976>; Thu, 10 Dec 1992 02:52:16 -0500
Received: by micor.OCUnix.On.Ca (smail2.5)
	id AA26107; 10 Dec 92 02:34:43 EST (Thu)
To: hyperc-l@calvin.sfasu.edu
Subject: Re: C Quiz
Date: 	Wed, 9 Dec 1992 21:34:43 -0500
Message-Id: <9212100234.AA26105@micor.OCUnix.On.Ca>
From: beejay@micor.ocunix.on.ca (Basil Johnson)
Status: R

 
Perhaps it is time to close the book on this thread.
I don't think we know what HyperC is doing in this instance.
I am convinced it's an HC bug, but I won't investigate any 
further because I haven't yet tried to understand the 
opcodes and nobody else has a good enough understanding of 
the LBIT instruction to shed light on the problem.  We'll 
come back to it I'm sure. 
 
I wanted to focus on why the code didn't work and asked that 
you not send alternate solutions.  Still, I appreciate the 
solutions and suggestions I got.  You know who you are.  
Thanks.
 
I tried all the suggestions.  The number of bytes used for 
the final 4 solutions were 0xf8, 0xfa, 0xfc, 0x100. 
The inkey() function with the smallest number of bytes was:
 
/*----------------*/
char inkey()
{
    static  char kb_rec;
    static char oa_key @0xc061;
 
    kb_rec = getkey(YES);
    kb_rec |=oa_key & 0x80;
    if (kb_rec & 0x80)
            (trace_sw ==ON) ? (trace_sw = OFF) : (trace_sw = ON);
    return(kb_rec);
}   /* inkey */
 
/*----------------*/
 
This whole thing started when I mentioned that I had written 
an assembly language peekb() to interface with C programs and 
I was told that that wasn't necessary.  What I have discovered 
is that it is not only unnecessary, it is 'costly'.  The 
assembly language counterpart of the 4 solutions above took 
0x208 bytes - a whopping 110% larger than the smallest all C 
solution.  At the '.s' level, the difference is 16 bytes.  Add 
to that the 57 bytes for the assembly module and we find that 
linking the asm module adds 199 bytes of overhead to the program.