chiu@princeton.UUCP (Kenneth Chiu) (07/28/86)
Well, I finally bought a compiler. Now I can do something real programming,
instead of just playing around. I have run into a few things that might
be bugs, though. If any who has the Manx compiler wouldn't mind some
correspondence, I would like to compare notes with some one when I run into
a problem.
1. The z editor doesn't seem to recognize :s/pat/repl/ commands. This is
quite a disappointment, since I use global substitutions sometimes.
2. The z editor also doesn't seem to recognize an options file. I tried
putting a z.opt file in the current directory and trying to define
ZOPT in the environment. And in the file I tried "ts=8", ":ts=8",
":set ts=8", "set ts=8", etc.
2. Many of the amiga functions (such as Lock) are defined: struct Lock *Lock().
I can't find such a structure defined in any of the .h files. I did find
struct FileLock, though, and the Lattice compiler seems to define as
struct FileLock whatever the Manx compiler has as struct Lock.
3. "grep -f BPTR foo.h" will not find "BPTR" in foo.h. "grep -f bptr"
will find "BPTR," though.
4. Their bulletin board for technical support doesn't answer. Maybe they
need some technical support too. :-)
--
Kenneth Chiu UUCP: princeton!chiu
Princeton University Computer Science Department BITNET: 6031801@PUCChiggin@cbmvax.cbm.UUCP (Paul Higginbottom) (07/30/86)
In article <805@princeton.UUCP> chiu@princeton.UUCP (Kenneth Chiu) writes: >Well, I finally bought a compiler. Now I can do something real programming, >instead of just playing around. I have run into a few things that might >be bugs, though. If any who has the Manx compiler wouldn't mind some >correspondence, I would like to compare notes with some one when I run into >a problem. > >1. The z editor doesn't seem to recognize :s/pat/repl/ commands. This is > quite a disappointment, since I use global substitutions sometimes. You're right - it doesn't have a replace command (I use MicroEmacs). >2. The z editor also doesn't seem to recognize an options file. I tried > putting a z.opt file in the current directory and trying to define > ZOPT in the environment. And in the file I tried "ts=8", ":ts=8", > ":set ts=8", "set ts=8", etc. > Right - they're document features which don't exist. >2. Many of the amiga functions (such as Lock) are defined: struct Lock *Lock(). > I can't find such a structure defined in any of the .h files. I did find > struct FileLock, though, and the Lattice compiler seems to define as > struct FileLock whatever the Manx compiler has as struct Lock. > Where is a struct Lock used or defined, or even mentioned? True, the AmigaDOS manuals mention Locks everywhere, but in terms of C, it means struct FileLock. >3. "grep -f BPTR foo.h" will not find "BPTR" in foo.h. "grep -f bptr" > will find "BPTR," though. > I don't use grep because search (while far from perfect) works ok, and is (apparently) faster. >4. Their bulletin board for technical support doesn't answer. Maybe they > need some technical support too. :-) >-- Call the PERSONAL technical support - they're pretty good. Even when I got on the tech BBS a few times ages ago, my questions were never answered. >Kenneth Chiu UUCP: princeton!chiu >Princeton University Computer Science Department BITNET: 6031801@PUCC Hang in there Kenneth, Manx C is an excellent package (I've been using it since before it was released). Version 3.3 should be out in August which should be a big enhancement (especially for 1.2 users/developers), and doubles will not be just floats in disguise, etc. Regards, Paul Higginbottom (Happy Manx User) Disclaimer: I do not work for Commodore, and my opinions are my own.
vanam@pttesac.UUCP (Marnix van Ammers) (08/01/86)
In article <557@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >In article <805@princeton.UUCP> chiu@princeton.UUCP (Kenneth Chiu) writes: >> >>1. The z editor doesn't seem to recognize :s/pat/repl/ commands. This is >> quite a disappointment, since I use global substitutions sometimes. > >You're right - it doesn't have a replace command (I use MicroEmacs). I'm used to the standard unix /bin/ed and am just beginning to learn z (and vi too for that matter). I think you can do the equivalent of g/pat/s/pat/repl/ via a macro. I recently found that I had received a bunch of files terminated with CR LF and I wanted to get rid of the CR's. So in z I built a macro (the command for that is ":>"). The macro I built was "$x-$" which would go to the end of the line, delete one character, go up one line and go to the end of the line (I think it's already at the end of the line, but just to be sure ...). After building the macro it is executed once. I was on the last line at the time. So now I did the rest of the lines with "9999v" which repeats the macro up to 9999 times. Wish I had my Manx book with me, but I think you can build a macro which will find a string, then delete that string, and then insert your replacement string. Then you can repeat execution of the macro n times with the v command. Marnix --
gary@mit-eddie.MIT.EDU (Gary Samad) (08/03/86)
In article <805@princeton.UUCP>, chiu@princeton.UUCP (Kenneth Chiu) writes: > Well, I finally bought a compiler. Now I can do something real programming, > instead of just playing around. I have run into a few things that might > be bugs, though. > > 1. The z editor doesn't seem to recognize :s/pat/repl/ commands. This is > quite a disappointment, since I use global substitutions sometimes. Yup, global search and replace is missing! My solution is to use Emacs! If you can get ahold of a set of 1.2 beta disks, C/As MicroEmacs is quite good. > 2. Many of the amiga functions (such as Lock) are defined: struct Lock *Lock(). > I can't find such a structure defined in any of the .h files. I did find > struct FileLock, though, and the Lattice compiler seems to define as > struct FileLock whatever the Manx compiler has as struct Lock. Use struct FileLock. I had this problem also. Also, if you are using the AmigaDOS functions you must CAREFULLY examine your code and determine when a FileLock that you pass in is going to be kept permanently by AmigaDOS and NOT free it, as well as when it is not going to be kept and free it. Send email for specific cases if you have trouble...I spent many hours trying to find 16 lost bytes... Gary
brent@orsvax1.UUCP (Brent Chivers) (08/06/86)
In article <557@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom) writes: >In article <805@princeton.UUCP> chiu@princeton.UUCP (Kenneth Chiu) writes: >>2. The z editor also doesn't seem to recognize an options file. I tried >> putting a z.opt file in the current directory and trying to define >> ZOPT in the environment. And in the file I tried "ts=8", ":ts=8", >> ":set ts=8", "set ts=8", etc. > >Right - they're document features which don't exist. I beg to differ. The following line, in a "proff" (public- domain nroff -me formatter) file, DOES work, giving me tabstops every 8 characters (".!" makes a non-printing comment): .! :ts=8 -- Brent Chivers {allegra|ihnp4}!princeton!orsvax1!brent or perhaps ORS Automation, Inc seismo!caip!topaz!pyrnj!orsvax1!brent 440 Wall St Phone 609-924-1667 Princeton, NJ 08540 FAX 609-924-2413 USA TELEX 4944924 ORSIN ------------- Disclaimer: Our business may be vision, but my views are my own. "If there is any place on earth that needs light, it is certainly New York." Felix August Bartholdy
hamilton@uiucuxc.CSO.UIUC.EDU (08/09/86)
>>>2. The z editor also doesn't seem to recognize an options file. I tried >>> putting a z.opt file in the current directory and trying to define >>> ZOPT in the environment. And in the file I tried "ts=8", ":ts=8", >>> ":set ts=8", "set ts=8", etc. >> >>Right - they're document features which don't exist. > >I beg to differ. The following line, in a "proff" (public- >domain nroff -me formatter) file, DOES work, giving me tabstops >every 8 characters (".!" makes a non-printing comment): > >.! :ts=8 embedded commands DO work in _editted_ files. that means you have to leave those little turds in _all_ your files. the complaint above was about the z.opt file, which is indeed broken. as a public service, here's the bulletin i got from manx's BBS. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton ------------------------------------------------------------------------------ Notes for beta 1 of Aztec C68K for the Amiga version 3.30a 7 - 1 - 86 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CC: 1) The compiler is using the new 3.4 front end which fixes the bugs with structure passing and also implements enumerated data types. This front end also generates information which will be used by a source level debugger which will be available later. 2) The compiler code generator has had a number of major revisions. The most significant is in the areas of floating point and register tracking. There is a potential for generating bad code, but I actually believe the new code generator is cleaner in design and therefore should be more robust. 3) There are 4 floating point formats supported on the Amiga. The compiler will generate code to use the appropriate format based on the compiler '+fx' option. The letter x should be one of the following: f - Motorola Fast Floating Point (the default) i - IEEE Double Precision Floating Point Emulation (Manx or Amiga) 8 - 68881 Floating Point There are also four math libraries supporting the different FP formats. They are m.lib, ma.lib, mx.lib, and m8.lib. 4) When using the FFP format, float or double register variables can be declared and will be mapped onto registers D4-D7 as appropriate. When using either the Amiga or Manx IEEE emulation, up to two register variables may be declared using the register pair D4-D5 and D6-D7. When using the 68881, four register variables may be declared using FP4-FP7. 5) The compiler defaults to using the Manx IEEE format internally since I don't require the MathIeeeDoubBas.library file this way. Constants are converted to FFP if necessary on output. 6) Hybrid combinations of IEEE and FFP are possible by compiling different modules with different options. This gives speed/accuracy choices to the programmer. Conversion between the two is done using two routines in the IEEE library. 7) There is a new option to the compiler, '+b' which enables stack depth checking code to be generated as part of the function startup sequence. It causes a "jsr __stkchk#" to be generated. The stkchk() routine is in the library and calls a routine called "__stkover" if it determines that the stack has grown too large or been corrupted. Currently, _stkover() prints a message and exits, but can be a user defined routine instead. 8) The include files are the ones from the 1.2 beta 2 release. They do not have the comments stripped from them. 9) Regarding number 2 above: since then I have added a number of attempted code improvements which are the likeliest to break. In particular, the compiler now generates the BTST, BCLR, BSET, and BCHG instructions. It also tries to not generate any redundant TST instructions. This is the one that may still not be quite right. The symptom will be that the compiler will generate a branch without generating some instructions that should have been there. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% AS: 1) The assembler now supports the following new directives which should allow all Amiga assembly language files to be assembled by our assembler. ifd ifnd ifc ifgt ifge iflt ifle ifne ifeq section fail cnop NARG 2) Arguments to macros can now be accessed using either %n or \n. \@ in a macro is converted to ".nnn" for the duration of the macro. Temporary labels of the form "nnn$" are also supported and are converted internally into "nnn$label", where label is the name of the most recently defined label. 3) In a macro, \0 or %0 is now replaced by the extension given to the macro name when invoked. 4) The Amiga assembly language header files are now included. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% LN: 1) The linker now supports scatter loading. The assembler object format had to change to make this work. As a result, all old object modules must be recompiled and reassembled to be used with the new linker. Also, you must use the new libraries. There are four models for linking. The different models are specified by using the '+s' option to the linker. There can be from 0 to 3 s's specified. The meaning of each is as follows: no '+s' This is the same as before, with all code being in one contiguous hunk. +s Each '.o' file or library to be separate hunks. All modules from a library end up in one hunk. +ss The linker places modules into a hunk until the hunk is at least 2048 bytes. It will then start a new hunk with the next module. +sss Each module is in a separate hunk. 2) The new linker will only generate a JMP instruction at the beginning of Hunk 0 if there has been an entry point defined and the entry point is not already at the beginning of Hunk 0. This has several effects. First, the old crt0.a68 assumed it was being entered by a JSR and will no longer work. Second, it is now possible to create printer drivers with the linker. 3) The linker now gives a warning message if a symbol not in the library overrides a symbol in the library. Thus, if you define a global data variable called "Exit", the linker will tell you when it sees Exit defined in the library as well. This may help prevent hard to find bugs where a call is made to data space or data is stored in code space. 4) The linker now supports segmentation using the '+o' options as defined in the manual. 5) When segments are used, the linker generates references to the symbol ".segload" which is defined in a library module, "segload.o". This module must be in the root segment for the program to function properly. 6) When segments are used, segments are loaded into memory as needed, and remain in memory until explicitly removed by the program. The program does this by calling the "unloadseg()" routine with the address of a function which is in the segment to be unloaded. 7) The environment variable used to specify where libraries can be found now supports multiple entries separated by a ';' or a '!'. 8) The linker will now automatically add a ".o" extension to files that have no extension. It will also check the current directory AND all directories defined in the CLIB environmnet variable. This means that if you want to link with "segload.o", you can just give the name and the linker will check the current directory and all the CLIB directories. 9) The linker supports Amiga object format modules and libraries. It will automatically detect that a module is in Amiga format, but it must be told that a file is actually a library. This is done using the '+l' flag which specifies that any amiga object modules detected are libraries until the next '+l' flag is encountered. If a library is encountered without the '+l', all the modules in the library will be included in the program. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Z: 1) The startup options now work. The name of the options file is either taken from the environment variable ZOPT or if ZOPT is not defined, then the name "devs:z.opt" is used. 2) A bug where lines of 3 characters when shifted didn't display correctly was fixed. 3) The <INSERT> and <REPLACE> messages weren't being updated correctly. 4) Z now supports dynamic memory allocation in 5K chunks. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% DB: 1) There is a new command in DB which allows output sent to the screen to be logged to a file as well. "> file" will start the logging. A second "> newfile" will close the first and open a new file, while ">" by itself will disable logging. 2) There is now a 't' command to DB which acts the same as 's', except when the instruction to be single stepped is a JSR or a BSR instruction. In that case, the debugger will single step once, and set a breakpoint on the return of the call. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% MISC: 1) The SETDAT program has been fixed to match the documentation. You don't have to type all the numbers anymore. 2) The bugs in lb have been fixed. 3) There is now a touch command. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% C.LIB: 1) The exec functions have been changed to work under 1.1 or under 1.2. 2) The new Amiga library functions added to 1.2 are now supported. In particular, DrawEllipse(), AreaEllipse(), the new intuition calls and the expansion architecture calls are in the library. 3) The WBenchMsg variable is now initialized by the startup code for compatibility. 4) strchr() and strrchr() have been added to the library. 5) The fexec() routine has been improved and should handle the CLI programs that it had problems with before. 6) The default startup code opens the MathFFP library since it is in the Kickstart and doesn't cost anything. The MathIeeeDoubBas library is opened by the version of the startup code in the ma.lib library. If you link ma.lib after c.lib, the library vector won't be set up and the program will crash unless you declare the MathIeeeDoubBasBase variable explicitly and open the library. 7) A bug in the localtime() routine was fixed. 8) fexecl(), fexecv(), execlp(), and execvp() now support the paths available under 1.2. 9) A routine called setenv() has been added to the library which adds or deletes environment variables from the environment. The calling sequence is: setenv(name, buf) char *name, *buf; where "name" is a pointer to the environment variable to be changed and buf is a pointer to the new value. If buf points to a null string, the variable will be removed from the environment. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% M.LIB: 1) ran() and fabs() have been added to the math libraries. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%