pl@sparrow.tut.fi (Lehtinen Pertti) (12/12/89)
I've been using Lattice 4.0 and now I had a chance to test 5.0.2
and found out following facts:
1)
In asm 'moveml xx(pc),...' generates still wrong offset.
2)
I can now use variables defined as __chip, but
following caused still sime problems.
char __chip s[128];
func()
{
int i = 0;
s[i] = 5; /* this works */
s[0] = 5; /* this won't */
}
And so ...
Well, above example isn't exact, but
point is that reference with variable as index was ok
but with constant wasn't.
Question is:
Are these ok with 5.0.4 and above.
Pertti Lehtinen
pl@tut.fi
--
pl@tut.fi ! All opinions expressed above are
Pertti Lehtinen ! purely offending and in subject
Tampere University of Technology ! to change without any further
Software Systems Laboratory ! noticewalker@sas.UUCP (Doug Walker) (12/13/89)
In article <10415@etana.tut.fi> pl@sparrow.tut.fi (Lehtinen Pertti) writes: > > I've been using Lattice 4.0 and now I had a chance to test 5.0.2 > and found out following facts: > > 1) > In asm 'moveml xx(pc),...' generates still wrong offset. We were quite surprised to hear this... which you seem to have known about since version 4.0. 5.04 fixed all REPORTED bugs, but this one has never been reported to us. Investigation indicates that *) The bug only happens with movem, move is safe *) It only happens with relocations - foo(pc) not 6(pc) Please contact Lattice tech support to report the problem and to get a patch for it. > 2) > I can now use variables defined as __chip, but > following caused still sime problems. ... (example deleted) > Well, above example isn't exact, but > point is that reference with variable as index was ok > but with constant wasn't. This has also not been reported and we could not reproduce it with any version of the compiler. I doubt seriously the problem exists in as simple a form as you have shown, or the compiler itself would have failed to compile, much less any test cases. Please get a sample program to Lattice tech support as soon as possible. Lattice tech support - (312) 916-1100 FAX - (312) 916-1190 or call the Lattice BBS or BIX. ***** *|_o_o|\\ Doug Walker, Software Distiller *|. o.| || | o |// "READY! FIRE! AIM! (Software under development!)" ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker
w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) (12/15/89)
(the following minor flame is not directed at you, Pertti) In article <10415@etana.tut.fi> pl@sparrow.tut.fi (Lehtinen Pertti) writes: > 2) > I can now use variables defined as __chip, but > following caused still sime problems. > > char __chip s[128]; Gag! Barf! Ack! Ooopthhhh! To quote from the bible of C, K&R second edition, pg. 233: A preprocessor line of the form # pragma token-sequence[opt] causes the processor to perform an implementation-dependent action. An unrecognized pragma is ignored. Why __chip? We've got the PORTABLE mechanism already. Why not use it? Was there some good technical reason? (__chip must go. This is not negotiable. ;-) The idea behind __chip is good, though. It would be really useful to have as a pragma. Edwin Reading legalese mush can turn your brain to guacamole. - RKMs A&I
martin@enuxha.eas.asu.edu (Ross D. Martin) (12/15/89)
In article <9532@microsoft.UUCP>, w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: > # pragma token-sequence[opt] > > causes the processor to perform an implementation-dependent action. An > unrecognized pragma is ignored. > > Why __chip? We've got the PORTABLE mechanism already. Why not use it? > Was there some good technical reason? (__chip must go. This is not > negotiable. ;-) Yes it is. :-) > > The idea behind __chip is good, though. It would be really useful to > have as a pragma. > > Edwin > Reading legalese mush can turn your brain to guacamole. - RKMs A&I I don't see what you have against __chip. It is portable. Just #define it to something harmless to do a port. I believe you can #define something to a null string, can't you? If not, there are several do-little modifiers out there that should work ok. Perhaps #define __chip static? Pragmas involve more typing to get less clear, clean code. Not a good idea in my book. Ross Martin
dirks@phao.eng.ohio-state.edu (William R.Dirks) (12/15/89)
In article <9532@microsoft.UUCP>, w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: > # pragma token-sequence[opt] > > causes the processor to perform an implementation-dependent action. An > unrecognized pragma is ignored. > > Why __chip? We've got the PORTABLE mechanism already. Why not use it? > Was there some good technical reason? (__chip must go. This is not > negotiable. ;-) The following is quoted from the Lattice Amiga Compiler User's Guide page G51 without permission. (I hope they don't get mad at me. ;) ) "The chip, far, huge, and near keywords are extensions to the ANSI standard. The standard requires that each keyword extensions [sic] be preceded by a double underscore, such as __near. The Lattice compiler accepts the extended keywords in this form as well as in the more natural form without the double underscores." I guess "__chip" is ANSI, but "chip" breaks the rules. I am in no way affiliated with Lattice. -=- Bill Dirks ...a large iron bar suspended across a vast dirks@kaa.eng.ohio-state.edu multitude of grapes...
usenet@cps3xx.UUCP (Usenet file owner) (12/18/89)
In article <411@enuxha.eas.asu.edu> martin@enuxha.eas.asu.edu (Ross D. Martin) writes: >In article <9532@microsoft.UUCP>, w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: >> unrecognized pragma is ignored. >> >> Why __chip? We've got the PORTABLE mechanism already. Why not use it? >> Was there some good technical reason? (__chip must go. This is not >> negotiable. ;-) How many Amiga programs that would need to use __chip use non-amiga specific stuff??? I would suggest that any program that needs __chip is not readily portable to begin with. Things would be different if AmigaOS ran on multiple architectures. Joe Porkka porkka@frith.egr.msu.edu
walker@sas.UUCP (Doug Walker) (12/19/89)
In article <9532@microsoft.UUCP> w-edwinh@microsoft.UUCP (Edwin Hoogerbeets) writes: (documentation on #pragma statements deleted) > >Why __chip? We've got the PORTABLE mechanism already. Why not use it? >Was there some good technical reason? (__chip must go. This is not >negotiable. ;-) #pragma is extremely non-portable. Each compiler can implement any #pragma keyword any way they wish, and you cannot #define a #pragma away. You can get rid of __chip simply by defining it to nothing. There is no portable way to define a non-portable feature. Period. However, according to the draft ANSI standard, December 7, 1988, section 4.1.2.1 pp 98 line 5: "All identifiers that begin with an underscore and either an upper-case letter or another underscore are always reserved for any use." and "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary identifier and tag name spaces" >The idea behind __chip is good, though. It would be really useful to >have as a pragma. And then what would the code look like? char data[SIZE]; #pragma chip data ( or perhaps ) #pragma datasect chip char data[SIZE]; #pragma datasect near Both of these are clumsy, hard to read and, as stated above, less easily ported than the __chip keyword. Actually, now that I think about it there is a portable way to define a non- portable feature. If every compiler variant had an assigned identifier, the #pragma directive could have been implemented #pragma <compiler-id> <pp-tokens> <newline> But there would be a question of who would define the compiler id's. In any case, ANSI did not define it this way, so there you are. ***** =*|_o_o|\\=====Doug Walker, Software Distiller======================= *|. o.| || | o |// "READY! FIRE! AIM! (Software under development!) ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker