Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.atari » ST COMM
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
ST COMM [message #282657] Mon, 13 January 1986 16:03 Go to next message
mdf is currently offline  mdf
Messages: 19
Registered: June 2013
Karma: 0
Junior Member
Article-I.D.: trwrba.1787
Posted: Mon Jan 13 16:03:03 1986
Date-Received: Wed, 15-Jan-86 08:24:12 EST
Organization: TRW EDS, Redondo Beach, CA
Lines: 21


Thiis article is  posted in response to inquiries I have received
with regards to ST COMM, a program I wrote with the HABA HIPPO C
compiler.  As posted, and using the HABA HIPPO C compiler, the program
comppiles and runs withoout error.  If one attempts to compile it using
the DRI C compiler provided with the development package, errors will 
result.  I was unaware of this until Alan Kenington wrote me.  His
analysis seems to make sense:
	HABA HIPPO C defines an 'int' as a 32 bit quantity.  DRI C
	defines an 'int' as a 16 bit quantity.  Alan says that the
	errors occur with the 'switch (c)' statement; and they are due
	to the different 'int' representations of the compilers.
I hope this helps anyone encountering these errors.  It has been a while
since I posted the source, and I am not thhat familiar with it anymore.
Maybe Alan will read this and repost his analysis for all to digest.

			Mark Falleroni
			Ogden Engineering Office
			TRW Defense Systems
			Ogden, Utah
			
Re: ST COMM [message #282662 is a reply to message #282657] Tue, 14 January 1986 22:47 Go to previous message
knnngt is currently offline  knnngt
Messages: 19
Registered: December 1985
Karma: 0
Junior Member
Article-I.D.: ukma.2466
Posted: Tue Jan 14 22:47:59 1986
Date-Received: Thu, 16-Jan-86 04:41:14 EST
References: <1787@trwrba.UUCP>
Reply-To: knnngt@ukma.UUCP (Alan Kennington)
Organization: Univ. of KY Mathematical Sciences
Lines: 93


	Actually, the reason I wanted to compile STComm was to use a 1200
baud modem I've got, which is just appalling using ST Talk. Believe it or
not, the local store is still selling this garbage. It owrks for xmodem,
but everybody but the computer store down the street seems to know that the 
VT52 aspects don't work on, for instance, vi. And I just wasted $40 on
a program called typesetter ST. It now lies on the floor. That's the last
time I get pressurised into buying garbage like that. From now on, I
reserve the right to walk out of a computer store without buying anything!!!
	Now my real reason for this note is to expound on my theory about what
is wrong with the ST Comm. Well, nothing, except that pass 1 (I think) of
the DRI C compiler gives a warning about multiply defined cases. You will
see clearly from the following excerpts why.   DRI has 16-bit ints, whereas
Hippo has 32-bit ints. Hence Hippo thinks F3, F2 etc. are different,
and DRI thinks they are all 0. Clearly the solution is to make c a
longword. One of the problems with C is that it cannot be machine-independent.
If every program refuses to use any larger integer than 65k, then that
is resources wasted, but the alternative is non-portability. The real
solution is, of course, to use
#define WORD short
#define LONGWORD double

or something similar, and then for different compilers, adjustments can be
made at teh beginning of the program. I haven't checked the rest of the
program. Nor have I run it with the corrected type for "c".
	While I'm on the topic of use of the top portion of a longword,
someone posted a warning a while ago that use of the top byte of
addresses was dangerous because it made the code non-upwardly-compatible
with later 68k chips. If the ST is ever going to use a 68020 chip, it's
going to need a major overhaul in the OS, because the top byte is used
with wild abandon!!!
	And now this....

#define F10 0x440000
#define F1 0x3B0000
#define F2 0x3C0000
#define F3 0x3D0000

###### about 150 lines of code ########

put_serial()
{
unsigned int c;
int wait;
short go_on,n,st;
char name[14];

inv_on();
printf("\n**** F10 = exit to MAIN MENU ****\n");
inv_off();

ctr = 0;
st  = OFF;
wait = 0;
cnt = 0;
go_on = 1;

while (go_on == 1)
{
 while ((n = conis()) < 0)    /* GET CHAR INPUT WITHOUT ECHO */
 {  				/* SCREEN */
	c = necin();
	switch (c)
	{
	case F3 : dsave_on();  /* SAVE TO DISK */
			  break;
	case F2 : transmit();    /* TRANSMIT FILE */
			  break;
	case F1 : psave_on(); /* SAVE FOR PRINTER */
			  break;
	case F10: go_on = 0; /* EXIT TO MAIN MENU */
			  if (psave == ON || dsave == ON)
				dump();
			  break;
	case HELP : help();
				break;
	default : auxout(c);	/* OUTPUT TO SERIAL PORT */
	}
}

###### simply hundreds more lines of code ######

	The second, third, fourth and fifth case statements are flagged
as multiply defining a switch. This is because they all look like 0 to
the compiler. Enough said. Most readers will either find this utterly
trivial or incomprehensible. I hope someone out there finds it useful.
	But the moral of the story, folks, is that you must find some way
of assuring either portability or ease of modification. This rotten C language
is so painful to read that no one really wants to go through your program
to find out how the compiler is going to misinterpret your code.
zzzzzzzzzzzzzzzzzzzzzzzzzzzz .............ak. The person who requested me
to post this explanation is not responsible for the nonsense therein.
zzzzzzzzzzzzzzzzzzzzzzzzzzzzz...............ak.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: 520 ST and non-Atari monitors?
Next Topic: Re: 520ST video outputs
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 02:41:44 EDT 2024

Total time taken to generate the page: 0.07770 seconds