Conference hydra::amiga_v1

    The upgrade to LMK for 5.04 (LMK version 1.07) has problems.  I
    could not get it to take any actions even for a simple makefile.
    Other users have reported the same behavior.  The problem apparently
    has to do with a non-zero signal bit in the invoking shells Task
    structure.  Lattice is aware of this problem.  A temporary workaround
    is to run LMK as a background task; an easy way to do this is to
    use an alias:
    
    	alias make run lmk
    
    Hopefully Lattice will supply a fix soon.

The 5.04 versions of "stdlib.h" and "string.h" contain inconsistent memory block
function declarations.  If you include both in your source, you will get
"external item attribute mismatch" errors from the compiler.  The relevant
declarations are:

in "stdlib.h":

extern void *memccpy __ARGS((void *, void *, int, unsigned));
extern void *memchr __ARGS((void *, int, unsigned));
extern int memcmp __ARGS((void *, void *, unsigned));
extern void *memcpy __ARGS((void *, void *, unsigned));
extern void *memset __ARGS((void *, int, unsigned));

extern void movmem __ARGS((void *, void *, unsigned));
extern void repmem __ARGS((void *, void *, int, int));
extern void setmem __ARGS((void *, unsigned, int));
extern void swmem __ARGS((void *, void *, unsigned));

"string.h":

extern char *memccpy __ARGS((char *, char *, int, unsigned));
extern char *memchr __ARGS((char *, int, unsigned));
extern int  memcmp __ARGS((char *, char *, unsigned));
extern char *memcpy __ARGS((char *, char *, unsigned));
extern char *memset __ARGS((char *, int, unsigned));

extern void movmem __ARGS((char *, char *, unsigned));
extern void repmem __ARGS((char *, char *, int, int));
extern void setmem __ARGS((char *, unsigned, int));
extern void swmem __ARGS((char *, char *, unsigned));

The declarations in "stdlib.h" are correct; Lattice suggests replacing the
declarations in "string.h" with those in "stdlib.h".  After making this change
you should re-compact "string.h":

	lcompact <string.h >INCLUDE:string.h

I've performed this fix and it did fix the problem.

The 5.04 patch to CPR has a major bug.  It is having trouble displaying doubles
and structures.  Displaying a double will sometimes crash the system, other
times just display a blank line.  Displaying a structure always crashes the
system!

Lattice is supposed to post a fix to their BBS soon.  I have not yet tested this
bug.

The startup file CATCH.A does not correctly set the re-run
bits when a memory error occurs.  This automatically causes
a Guru when the is a page protection violation.

John

    I posted a bug for Lattice that timer() crashses the system at run
    time.  They say they are fixing a simpler problem that should fix this. 
    Note that there are now two timer()'s in timer.h; I didn't know that C
    could overload like Ada.
    So I may learn how to use the timer device in the meantime.
    Tom

    I finally made a program that had worked under lattice c 5.02 work
    under 5.04.  I used more advanced C features, which I had learned since
    the first version, including arrays of structures, more pointers,
    static variables, moving unnecessary globals down into the routines
    that need them, and so on.
    However, I had bad problems with the Lattice drand48 function and the
    Lattice timer function.  As soon I replaced these with the ANSI rand
    (and srand) functions and the AmigaDOS timer device, the major problems
    stopped.  The program (an automatic music composition program, the
    computer improvises its own music) works OK now. whew.
    I have a feeling that I should avoid functions marked "Lattice" in the
    library documentation.  There are also functions marked Amiga, Ansi,
    Unix.  I will stick to these.
    Tom

    There seems to be an undocumented change (read "bug") in the v5
    compiler which impacts on use of OML (Object Module Librarian). 
    
    In v4, and according to the v5 documentation, the module name in an
    object file was set to the name of the object file (eg lists.o). When
    the module was loaded or replaced in an object library (oml local.lib r
    lists.o) it went in with a module name of "lists.o". However, something
    in the compiler (LC1,LC2) has changed between v4 and v5 because the
    module name in v5 is set to the name of the source file (eg lists.c).
    This has no impact on compiling or linking, but if you replace a v4
    object module in a library with the same object compiled under v5 you
    get "Duplicate symbol" messages from OML. Listing the library (oml
    local.lib l) shows the duplicate messages and shows two modules present
    with the same symbols but different module names (lists.c and lists.o).
    I used OMD to confirm this after compiling the same object file under
    v4 and v5.
    
    The "fix" is to delete the library and rebuild it from scratch with v5
    object files (or never to replace a v4 module with a v5 module).
    
    If anyone on the net in the US has electronic access to Lattice I'd
    appreciate you posting this to the support BBS. It's very difficult
    getting dialed-up from "downunder". I'm using v5.04 (installed exactly
    according to their supplied procedures). Thanks.
    
    Simon.

	I just dusted off my Lattice 5.04 (never did get up
	to 5.05 or SAS/V5.1) C compiler.  Trying to use LMK,
	it seems to work OK for explicit target-dependency
	rules, but generic transformation rules do nothing.

	My sample file:

	.c.o:
	  lc $*

	file.o:    file.c

	I've experimented with all sorts of permutations on
	this, to no avail.  Am I missing something, or is this
	part of the LMK problem that .1 refers to?  Is this
	fixed in the current SAS/C?  (I'm using LMK V1.07)
	Thanks for any help...maybe it's time I updated my 
	software..

>	.c.o:
>	  lc $*
>
>	file.o:    file.c



I've used this many times with no problem. I usually have an executable
target as well:


	$(EXE) : $(OBJS) $(MAKEFILE)
                 $(LINK) $(LFLAGS) $(OBJS) $(LIBS)

dumb question: is your file.o in the directory and/or newer than the .c file?

john

	Well, as .1 suggests, 'run lmk' will work where
	just 'lmk' won't.  Strange.

	P.S. Thanks John

	I'm trying to decide whether or not to buy Lattice.....

	It seems that C++ includes a compiler, assembler, linker, 
etc., but I can't figure out if it really is a superset of SAS/C or 
whether its founded on it (in which case I'd need the base).  Would 
C++ just come with documentation and "utilities" that assume a C 5.xy 
base of some sort ?

	Also, is anyone using NorthC, from FF 384 ?   I have it, it 
seems to do at least some of the right things, though I havn't yet
exercised it thoroughly, I'm a REAL beginner.  How buggy is it ?  My
fear with this is that I want to learn C (& C++) *_NOT_*   "bugs and
work-arounds".  OK, everything has some bugs - -

	R

Re: .11

As far as I know, Lattice C++ has not been updated since it was released.
Part of the reason for this might be that Lattice is trying to write
their own C++ compiler rather than just offering a port of AT&T's
cfront "preprocessor".  Unfortunately, a C++ compiler is at least an order
of magnitude more complex to write than a C compiler, and I suspect
that they are floundering.

Personally, I wish they would offer upgrades to newer versions of
cfront.

Lattice C++ is not a superset of Lattice (or now SAS) C.  Although
Lattice C++ comes with a version of Lattice C to compile the output
of cfront, it is a version of Lattice C that is a couple of
major versions old.  Lattice C++ doesn't ship with full header
files or utilities, either.  I seem to remember you don't
get the standard C libraries with C++ (you definitely don't
get any documentation for them).  You do get a C++ specific
library plus documentation for it.

If you are serious about programming in C as well as C++, you
should buy both C and C++.  (You can use the new C compiler with
the old C++.)

Maybe someone can help me out.  I am learn C and am using 
the SAS v5.1 compiler on my amiga.  When I run q7 it works fine.  When I run 
q8 the answer comes out as, "(x-y)/(x*y) equals Inf0.000000".  They are
almost identical except that I am trying to use a function to perform the
calculation.  Can you tell me why I am not getting a good return?
    

I am compiling with the "lc -Lm command".  Here are the two sources.
    

/* q7.c--calc diff/product of two entered floating values */

#include <stdio.h>
main()
{
	float x, y, z;
	
	printf("\nPlease enter 2 real numbers x,y.  I will calculate"
	 		" (x-y)/(x*y).\nEnter q to quit.\n?");
	while ( scanf("%f%f", &x, &y) == 2 )
	{
		z = (x - y) / (x * y);
		printf("\n\n(x-y)/(x*y) equals %f", z);
		printf("\nEnter the next two numbers: ");
	}
	printf("\n\n          Bye!\n\n");
}
-------------------------------------------------------------------------

/* q8.c--calc diff/product of two entered floating values using func */

#include <stdio.h>
main()
{
	float 	ans, x, y;
	float	calc();
	
	printf("\nPlease enter 2 real numbers x,y.  I will calculate"
	 		" (x-y)/(x*y).\nEnter q to quit.\n?");
	while ( scanf("%f%f", &x, &y)  == 2 )
	{
		ans = calc(x,y);
		printf("\n(x-y)/(x*y) equals %g", ans);
		printf("\n\nEnter the next two numbers: ");
	}
	printf("\n                   Bye!\n\n");
}	


	float 	calc(a,b)		/* calc() returns type float */
	float 	a, b;
	{
		float 	c;
		
		c = (a - b)/(a * b);
		return c;
	}


mark

    

    >	        	ans = calc(x,y);
    >     		printf("\n(x-y)/(x*y) equals %g", ans);
                                                      ^
           Are You shure this is correct?  ___________|

>Note 3095.13                   Lattice C 5.04 bugs                      13 of 13
>DECWET::DAVIS "nice computers don't go down"         62 lines   6-DEC-1990 00:51

>/* q7.c--calc diff/product of two entered floating values */

>                printf("\n\n(x-y)/(x*y) equals %f", z);

>-------------------------------------------------------------------------

>/* q8.c--calc diff/product of two entered floating values using func */

>                printf("\n(x-y)/(x*y) equals %g", ans);
                                              ^^-------->in q7 you use %f

Sorin

Re: .11

I've been in touch with the SAS folks since they took over responsibility for
the Amiga C/C++ products. I had heard from Lattice before the switch that they
were working on a true C++ compiler, and so wanted an update on progress/status
of the project.

The tech support folks at SAS tell me that they expect a release sometime in-
(gasp) mid-1992! I guess this indicates that (a) they too think that a C++
compiler is a beast of a different class; and (b) they have faith that the Amiga
and C++ are both going to be around for a while.

(Hey .13, I disagree with your tag line! Nice computers *do* go down! However,
they do it gracefully and when they're told to, rather than suddenly without
warning when you're busy doing something.)

        <<< Note 3095.17 by ULTRA::BURGESS "Mad man across the water" >>>
                            -< Syntax or sin-tax ? >-


	OK, so yesterday I got hold of the K & R book - today I know 
it all, right ?

	WRONG !

	Not wanting to say Hello to a case sensitive world, I thought 
I'd try some bit twiddling instead {I know, high level languages ain't 
for bit twiddling}.

/*  dumb program to reverse a count pattern, i.e. least signif bit of
count is most signif bit of flopped, etc.  */

#include <stdio.h>
main ()
{
	int flips[16], flopped, count, i;

/*	fill the flips array with powers of 2	*/

	flips[0] = 1;
	for (i = 0; i < 15; ++i)
		flips[i+1] = flips[i]*2;

/*	outer loop starts here	*/

	for (count = 0; count < 100; ++count)
	{
	flopped = i = 0;
	while (i < 14)		/* this is wrong; but I want to stay 
				well clear of the sign bit, 
				for now anyway */

	{
/*	for each bit that is in "count" - OR a mirror bit into
	"flopped" - the mirror axis is somewhere around bit 7 */

	if (count & flips[i]) {flopped = flopped | flips[14-i];}	
							/* PROBLEM HERE */
	++i;
	}							^
	printf("%9o\t%9o\n", count, flopped);			|
	}							|
}								|
								|
								|
								|
								|
					The Amiga (NorthC) wants the 
semi-colon to the right of the closing curly brace.  VaxC want is to 
the left of the curly brace.  I don't know enough to know whether 
there is a right or wrong - the program works on either machine, I'd 
like to make the same code work on both machines, obviously.

	Reg

    re: .13
    %f or %g or %e it still fails to function.  I tried using double rather
    than float with the same results.  The %g is in q8 because I was trying
    to determine if the problem was in my format specifiers.
    
    mark

I think that VAXC is correct.  A if (x) { y; }  is best, and a 
if (x) { y; }; should be fine also.  The extra ; isn't needed because
the statement is completed by the } but it won't hurt.

The problem might be avoided by a little judicious formatting.  C is cryptic 
to begin with, so please take the K&R (or your own) standards to heart and 
increase the readability a bit.

Something like below, is generally what K&R recommend, and the standard that I
like to use.  Effective use of whitespace, commenting, etc, are all very
important habits to get into.

As a side note, remember that different architectures will use different
"endian" for numeric representation.  If you want to set bit X, it's 
generally best to  use a shift operation, rather than a arithmetic one.

for (i = 0; i < MAXBITS; i++)
    flip[i] = (1 << i);

Also remember that int is rather ambiguous and you might want to determine
exactly how many bit's you have to work with by something like...

#define MAXBITS (sizeof(int)*8)		/* assuming 8bits/byte */

Portability can be a lot of work, regardless of how "portable" C is supposed
to be.  Don't take the criticism harshly, it might save hours of late night
hacking... :^)

Steve - four years of non-stop C, and what do I know?

#include <stdio.h>
#define MAXBITS		(sizeof(int)*8 - 1)	/* skip high order bit */

main ()
{
    int flips[MAXBITS+2], flopped, count, i;

    /* fill the flips array with powers of 2	*/

    flips[0] = 1;
    for (i = 0; i < MAXBITS; ++i)
	flips[i+1] = flips[i]*2;

    /*	outer loop starts here	*/

    for (count = 0; count < 100; ++count) {

        /* 
	   this is wrong; but I want to stay well clear of the sign bit,
	   for now anyway 

	   for each bit that is in "count" - OR a mirror bit into
	   "flopped" - the mirror axis is somewhere around bit MAXBITS/2
        */

	flopped = i = 0;
	while (i < MAXBITS) {	

	    if (count & flips[i]) {
		flopped = flopped | flips[MAXBITS-i];
	    }	
 
	    ++i;
	}						
	printf("%9o\t%9o\n", count, flopped);		

    }							
}							

Re the calc() function problem: please post your compile/link commands.

I'm back.  q8 seems to work for me under VAXC, but it definitely is having
problems on the Amiga.  My guess is it's some kind of problem with 
the linkage of the math library.  Are you using FFP or the IEEE type
libraries?  What the command to compile (>lc -Lm q8)?

Steve

    Q8 worked for me under VAXC also.  the lc -Lm command uses the Lattice
    IEEE FP library.
    
    m
    

    Latice is having an 'inventory reduction sale'.
    "While Supplies Last:"
    C++				$150.
    Communications Library	$ 50
    Compiler Companion		$ 20
    dBC III Library		$ 25
    Panel			$ 25
    "Other Software as low as   $ 15"
    
    Call Lattice Sales at:
    (800)444-4309 or (708)916-1600
    
    
    The above is an add in the Dec. '90 AmigaWorld.
    
    I got good service, my C++ arrived in 6 days.
    
    The C++ is marked: 
    "This product is sold with limited
    technical support.
    
    An Intro to Objected-Oriented Programming and C++
    is no longer included."
    
    Well, I'm not shure what the 'limited support' means,
    but I think it refers to their hotline and update service.
    Does anyone know whether this is a policy change for this
    sale, or is this now the std. policy??
    
    Am also curious about the dropped book, but since I've got a
    couple of C++ books anyway, I don't care. The Lattice C++
    doc. looks very good. At first inspection appear more coherently 
    written than the Lattice C V5.0 docs which were good, but sometimes assumed
    a pretty knowledgable user, and could be better structured. Anyway,
    the C++ manuals: C++ compiler - about 200 pgs, and C++ Reference Manual
    - about 300 pgs are easier to deal with than the
    C manuals.
    
    	Installation was easy, I already had C installed, so I just clicked
    their C++ install Icon, selected 'hard drive' and 'no C'. this
    generated a script file which I edited to delete the copying of blink
    from the C++ kit. I executed the script file which copied for a few 
    minuites, then compiled my first Amiga C++ program. (After I moved
    the sources out of RAM DISK: to something else, as I was getting the
    disk requestor asking for volume 'DISK', apparently the C++
    compiler was droping the 'RAM'.
    
    Hope this saves someone some $, as this price is cheaper than Abel or
    anyone else I've seen.
    
    Verell