ditzel@ssc-bee.UUCP (Charles L Ditzel) (05/31/86)
Subject: Megamax C Newsgroups: net.micro.atari16 Distribution: net I recently received Megamax C and my first impressions are very favorable. Having *suffered* with trying to deal with an Apple Mac Plus and both DeSmet C and Aztec C ...i appreciate what Megamax has done on the Atari. Of course some of the problems with the Mac Plus are non-existent on the Atari. For starters, the ST has had a hierarchical file structure from the very beginning...(Apple's recent introduction of their HFS is surprising in its lateness and is causing problems with existing software packages that depend on their original flat file structure). In any case...on to the good stuff... The Megamax development package comes with two single sided diskettes and a thick binder with the documentation. The layout of this binder is : 1: The Atari ST Environment 2: Language Extensions 3: The Linker 4: Megamax Shell 5: Megamax Editor 6: Megamax Resource Construction Program 7: Librarian 8: Disassembler 9: Code Improver 10: Unix Compatible Routines 11: GEM AES Routines 12: GEM VDI Routines 13: Bios Routines 14: Xbios Routines 15: GEM DOS 16: System Globals 17: Error Codes Appendix A: Header Files Appendix B: System Limits and Extensions Appendix C: Keyboard Codes Index (Yes - shockingly an *index*. Anyone that has had anything to do with both the Manx Aztec compiler documentation for both the PC and the Mac may faint...) The diskettes included contain: -compiler -system library -graphical shell -desk accessory library -linker -editor -header files -double precision library -examples -code improver -resource construction program -disassembler -librarian -megaroids (a game written in Megamax C) A note : a make facility is included. Apparently for $50 one can also get the source code listings of system library functions. (these are not included in the Megamax development package). Updates will cost $20. The Megamax C package is capable of being used off the: 1) GEM Desktop 2) Beckmeyer Micro C Shell (unix-like shell) or COMMAND.TOS (I haven't tested this out) 3) Megamax Graphical Shell Graphical Shell: So far not only have i found the Megamax graphical shell(gs) tolerable but also likeable. Tho' my preference i suspect will eventually be the Micro C shell. So far i have found the gs pretty good. Editor: The editor that is supplied is from acceptable to good. I *really* disliked the editor supplied with the Atari/DRI development package. The megamax editor is quirky on two points: find and the arrow keys - if these are editor quirks and not my own doing. Resource Construction Program: Is similar but not identical to the DRI RCS. The DRI RCS has some trash can and clipboard icons not found in the Megamax version. The Megamax RCP instead uses a pull down menu to accomplish these functions. I didn't use those icons for much but some people may miss them. Megamax improved significantly over RCS by including an icon design tool. Additionally they include an options menu that has a sort (sorts the tree structure of the immediate children of the selected object). Librarian: I have not got around to looking at this. Disassembler: ditto. Code Improver: ditto. The code improver "performs simple branch optimizationss on an object file that has never been in a library. Unix compatible routines: abs,atof,close,toupper,tolower,_toupper,_tolower,toascii,creat,isalpha, isupper,islower,isdigit,isalnum,isspace,ispunct,isprint,iscntrl,isascii, exit,_exit,fclose,fflush,ferror,feof,clearerr,fileno,fopen,freopen,fread, fwrite,fseek,rewind,ftell,getc,getchar,fgetc,getw,gets,fgets,lseek,malloc, free,calloc,open,printf,fprintf,sprintf,putc,putchar,fputc,putw,puts, fputs,rand,srand,read,sbrk,scanf,fscanf,sscanf,setbuf,setjmp,longjmp, strcat,strncat,strcmp,strncmp,strcpy,strncpy,strlen,strtol,atal,atoi,ungetc, unlink,write footnote: i asked megamax if a system() function existed...they pointed to execv(name,argv) --- (char *name; char *argv[]) as existing but being undocumented...i tried this and couldn't find it... AES,VDI,etc: I haven't had time to examine AES, VDI, Bios and Xbios functions but a cursory glance tells me I don't seem to be missing anything that I have in the DRI/Atari development package. I have ported a couple of things that seem to work nicely. The port times were pretty good. Another nice feature in the documentation is a listing of all the system globals, errors, header files. C compiler: I had program (written with DRI C) that put up a menu bar and window it ported in 10 or 15 minutes. Of that time 95% of the time was spent in the editor. The main problem stemmed from using some of the unportable #defines from DRI's <portab.h> - BYTE, LONG, WORD.. Megamax C complained...about the DRI RCS generated C code using these keywords...i changed these to the more portable char, long,int and all was well...The compiler is pretty fast (tho' i have a one megabyte ST which helps :) *compiler is a one pass compiler. *space used by a program at run time is divided into a number of segments. Each segment may contain up to 32KB. *8KB stack space. changeable by modifing the init.c file in the system library. *linkable object code is generated directly. no assembly post-pass. *overlay mechanism *inline assembly code Linker: *smart linker - loads only what is need. *gives stats CONCLUSION The overall package is a streamlined well documented one (includes explanations a la unix man pages of all unix,aes,vdi,bios,xbios functions). In my mind it accomplishes in considerably less paper what the messy Manx Aztec C documentation can not do in hundreds of pages. This mini-review is should in no way be taken to be a comprehensive examination of the product. These are just my observations. My current feeling about the package is very positive. It seems to be the environment I was hoping to find. The fact that i can use it in a number of environments (Micro-C shell,Command.tos,GEM desktop, megamax graphical shell) provides an even more flexible package.
lbl@druhi.UUCP (LocklearLB) (06/04/86)
In article <564@ssc-bee.UUCP>, ditzel@ssc-bee.UUCP (Charles L Ditzel) writes: > > I recently received Megamax C and my first impressions are very favorable. > I too recently purchased Megamax C. I really like the package and agree with what Charles wrote about it. I do have a couple of observations that I would like to share. 1) I/O redirection does not work correctly with Megamax C. I first heard about this on Compuserve, and I have since tried it for myself. I tried redirecting output from a program supplied with the Mirco C shell into a program compiled with Megamax. The Megamax program is supposed to filter the standard input and print some results on stdout. The Megamax program doubled the input lines and inserted garbage characters before sending output to stdout. If stdin was not redirected in the shell, then the program worked correctly. I also tried redirecting stdout and the program crashed! Obviously this is a bug in the libraries that needs to be fixed. Especially since the documentation states explicitly that i/o redirection should work correctly. I must add, however, that this is the only major bug that I have heard about, or experienced. Everything else seems to work as advertised. 2) The icon editing feature of the RCS supplied with Megamax is good, but I wish you could save/load icons to/from the disk. This would be a timesaver when using a set of "standard" icons in an application. 3) My overall impression of the package is very favorable. The documentation is fairly comprehensive and mercifully concise. Developing programs with this package is much more pleasureable than with the developer's kit. I have a one meg 520ST with a half-meg ramdisk. I can fit everything needed for the edit/compile/link cycle (compiler, linker, headers, libraries, editor, shell) on the ramdisk and still have enough space (>100K) for my source files. The compile/edit cycle is great when running under the graphical shell. First you edit the program, then compile. If the compiler finds bugs, the editor is reinvoked and loads your source file in one window and a file containing your error messages in another. The error messages even make sense! Since you are running under the ramdisk everything is very fast and convenient. It certainly blows away the DRI development environment in terms of productivity and ease of use. If you don't need to compile programs that redirect i/o, or if you already have the developer's kit for compiling those kinds of programs ( I do ), then I heartily recommend Megamax C. Barry Locklear AT&T Information Systems Labs Denver, CO ihnp4!druhi!lbl (303) 538-4954
bammi@cwruecmp.UUCP (Jwahar R. Bammi) (06/10/86)
I have been reading the Megamax Mini reviews with interest. I agree 100% with the comments about its speed etc. I was just a little surprised that no one mentioned some of its flaws and better known bugs. Flaws: - I am shocked that no one mentioned the fixed sized 32K text/data/bss segment code model. Ok you can get around the text segement by using the overlay (non standard C), but how about data (you cannot malloc and statically initialize it, so you end up writing a malloc followed by an init routine). Doing a malloc for each data structure larger can 32k in the bss segement can get painful too, especially when porting large programs. Anyone who has written a program more than a couple of line long knows what a headache fixed sized segments can give you. -Shorts are 1 byte long. One of the entusiasts here just got burned on that one. -No forward pointer reference of typedef'ed structures (because of its one pass nature, and short sightedness of the parser implementor). This broke a couple of my programs. Well known errors that come to mind: - Comparison of floats. - Sizeof struct arrays bombs compiler. - I have not been able to try the release version to verify if the preprocessor errors have been fixed. I continue to stick to Alcyon with a hard/ram disk. It is very livable. -- Jwahar R. Bammi Usenet: .....!decvax!cwruecmp!bammi CSnet: bammi@case Arpa: bammi%case@csnet-relay CompuServe: 71515,155
braner@batcomputer.TN.CORNELL.EDU (braner) (06/13/86)
[]
Although these objections hold, I would even overlook
segmentation (!) to get a bug-free (?) malloc() and a 15 sec
compile & link time (on RAM disk). For my (scientific) work,
the worst bug was the floating point comparision bug (it
claimed that -2 is greater than -1). 'Was', because here...
... (ta-da!) is the fix:
I took a close look, using the mmdis disassembler,
at the double.o file (extracted from the double.l library with
the mmlib program.) Only one (1) byte is wrong, looks like a typo.
In the routine _fcom, where it says BSET #31,D1 it should say D2.
To patch it, use the following 'bth' program (compile it with mmcc).
Bth.prg translates the bytes of any file into both hex and
ASCII representation. The output can be edited on any text editor,
and then fed into the htb program (posted earlier) to get it back
into binary. (Only the hex part needs to be changed, the ASCII part
is treated as a comment.) (Yes, Virginia, there is no way to assemble
the output of mmdis!)
In this case, tell bth.prg to read double.l. In the output file,
look (on line 47) for the sequence "46 82 46 83 08 C1".
Change the C1 to C2. Run it through htb.prg to create newdbl.l,
and your done. From now on, mmlink yourprog.o newdbl.l.
/* Program to create a hex file from a binary file.
by Moshe braner, 860613.
*/
#include <stdio.h>
#define hinibble(b) (((b)>>4) & 0x0F)
#define lonibble(b) ((b) & 0x0F)
#define tohex(b) ((b)<0xA ? ((b)+'0') : ((b)-0xA+'A'))
main() {
register int c, b, i, t;
int n, m;
FILE *infp, *outfp;
char infname[80], outfname[80];
char col[16];
printf("\n\nBinary To Hex conversion program. MB 8606.\n\n");
printf("Enter name of source file: ",stdout);
gets(infname);
/* open file with "br" to avoid skipping of '\r's
by Megamax library
*/
if ((infp=fopen(infname,"br")) == NULL) {
printf("cannot open source file!\n");
exit(0);
}
printf("Enter name of output file: ");
gets(outfname);
if ((outfp=fopen(outfname,"w")) == NULL) {
printf("cannot open output file!\n");
exit(0);
}
m = 0;
for (n=0; ; n++) {
b=getc(infp);
if (b != EOF)
col[m++] = b;
if ((b==EOF && m>0) || m>=16) {
for (i=0; i<m; i++) {
t = col[i];
c = tohex(hinibble(t));
putc(c, outfp);
c = tohex(lonibble(t));
putc(c, outfp);
putc(' ', outfp);
}
for (; i<16; i++) {
putc(' ', outfp);
putc(' ', outfp);
putc(' ', outfp);
}
putc(' ', outfp);
putc('*', outfp);
putc(' ', outfp);
for (i=0; i<m; i++) {
c = col[i];
if (c>=' ' && c<='~')
putc(c, outfp);
else
putc('.', outfp);
}
putc('\n', outfp);
m = 0;
}
if (b == EOF)
break;
}
printf("\nRead and translated %d bytes.\n", n);
}
/* - Moshe Braner, Cornell, 607-272-3487 */