HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (10/01/90)
While hunting a suspected bug in c68, I found that the ST MINIX as is
broken:
sub.l #0xFFFF0001,...
sub.l #0xABCD0001,...
sub.l #0x7FFF0001,...
are all converted to
subq.l #1,...
This seems to be problem with int/long inside the code.
can anyone who has the as source tell me exactly *when* this error occurs,
so that I can avoid these situations in the compiler output, e.g. negate
the constant and exchange add with sub. If you do not have the time, it
does not matter if you send the sources to me.
I will delay the patch#4 posting until this has become clear to me.
C.v.W.eesrajm@cc.brunel.ac.uk (Andrew J Michael) (10/03/90)
In article <32002@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > While hunting a suspected bug in c68, I found that the ST MINIX as is > broken: > sub.l #0xFFFF0001,... > sub.l #0xABCD0001,... > sub.l #0x7FFF0001,... > are all converted to > subq.l #1,... > [stuff deleted] Quite correct - how amusing ...... For those looking at this, the problem does not occur with the ACK assembler running as a cross-assembler on a Sun, so either the ST assembler sources are different to the generic ACK ones, or we have been bitten by yet another sizeof(int) bug. Sorry I can't fix it myself or be more helpful, but Transmediair are still resisting any of my attempts to get them to sell me the ST compiler sources ! Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Emulation is the sincerest 85 Hawthorne Crescent form of pottery." West Drayton Middlesex - William Frend De Morgan UB7 9PA
johan@philica.ica.philips.nl (Johan Stevenson) (10/04/90)
In article <32002@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >While hunting a suspected bug in c68, I found that the ST MINIX as is >broken: >sub.l #0xFFFF0001,... >sub.l #0xABCD0001,... >sub.l #0x7FFF0001,... >are all converted to >subq.l #1,... > Apparently I have fixed the bug in April 1990. The fixed 'as' binary is included in MINIX-ST 1.5. -- Johan W. Stevenson johan@ica.philips.nl Philips TDS ICA
eo@ansa.co.uk (Ed Oskiewicz) (10/05/90)
Dear Andy, Johan, Frans Regarding Johan's comment: > Apparently I have fixed the bug in April 1990. The fixed 'as' binary is > included in MINIX-ST 1.5. I am probably going to be one of many to request this but is it possible for the new as binary to be posted for those of us who started with ST 1.1? I don't recall one in the 1.5.x updates. Cheers, Ed Oskiewicz (eo@ansa.co.uk)
eesrajm@cc.brunel.ac.uk (Andrew J Michael) (10/06/90)
In article <32002@nigel.ee.udel.edu>, HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: > While hunting a suspected bug in c68, I found that the ST MINIX as is > broken: > sub.l #0xFFFF0001,... > sub.l #0xABCD0001,... > sub.l #0x7FFF0001,... > are all converted to > subq.l #1,... > (stuff deleted) > > C.v.W. On examining the genuine P-H 1.5 distribution for Atari and Amiga, I find that the assemblers are different. What's more, they are both different from my existing version, which came from ST 1.1. For example if I try size: 27458 8070 13286 100000 148814 /user/atari/bin/as 29984 9600 13260 100000 152844 /user/amiga/bin/as 26352 7908 13286 100000 147546 /usr/bin/as Both my original assembler and the 1.5 ST version exhibit the problem above. The Amiga version doesn't. So if you want a working assembler, use the Amiga version .... Andy Michael -- Andy Michael (eesrajm@cc.brunel.ac.uk) " Emulation is the sincerest 85 Hawthorne Crescent form of pottery." West Drayton Middlesex - William Frend De Morgan UB7 9PA
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (10/09/90)
It is clear to me what the source of the error is: an 'int' where a 'long' belongs. On a Sun, ints really are longs, so the error does not occur. C.v.W.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (10/09/90)
I suspect it was an int/long mismatch. Is it possible to distribute the binary netwide - I remember this policy has been applied to the PC compiler updates. C.v.W.
croes@fwi.uva.nl (Felix A. Croes) (10/11/90)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >Is it possible to distribute the binary netwide - I remember this policy >has been applied to the PC compiler updates. Or maybe something could be done to make the new binary qualify as a "patch" - xor with the old binary or something like that. And the same for other binaries that have changed (are there any? The crc's for the ST 1.1 binaries are: 45606 100243 cem 64475 67879 cg 05779 33414 cpp 52776 29847 ld.old 32936 33211 opt ld is called ld.old because I use my own linker/loader) If the ST and Amiga assembler binaries are different then one of them should be better than the other one (I suppose). So maybe some other people, apart from upgraded Minix ST users, would be interested. -- Felix Croes (croes@fwi.uva.nl)
johan@philica.ica.philips.nl (Johan Stevenson) (10/11/90)
Apparently I was wrong. Even the MINIX-ST 1.5 versions fails. It does work however if the same source runs on a 32 bit 'int' machine. I am trying to sort this out. I will post a working binary here. Please wait. -- Johan W. Stevenson johan@ica.philips.nl Philips TDS ICA