Newsgroups: comp.sys.transputer From: bailey@cvo.oneworld.com (Kirk Bailey) Subject: Re: ST20450 bug?: When GT in not greater than. Organization: One World Internetworking, Inc. Date: 18 Aug 1997 02:02:41 -0700 Message-ID: <5t933h$qmr@alsea.cvo.oneworld.com> Mark Booth writes: >In article , Wayne Fisher systems.on.ca> writes >>We're using the ST20450 in one of our products and have finally >>tracked down an intermittent problem we were having with it. We have >>isolated the bug down to a few lines of C code, and the result has us >>a little worried. It appears as though the gt instruction does not >>always work correctly. >Good grief, someone stateside using transputers, let alone a T450. *8') >>I've attached two pairs of C and assembly files that demonstrates the >>problem on our system, with the hope that someone else can verify this >>problem. We use a version of the Logical Systems Transputer Toolset >>that we have modified to suit our needs wrt the ST20450. >Does the "Logical Systems Transputer Toolset" implement the ST2450 bug >workarounds? >We use the SGS 4th generation Occam toolset (D7405A) which implements >all the workarounds that it can. >>We have verified that the exact same C code when compiled for, and ran >>on, a T425 works correctly. I have also verified that the assembly >>files generated for the T425 and the ST20450 match instruction for >>instruction. I have also verified that the executable code, generated >>for the following sequence of instructions, contains the correct >>opcodes. >Code for ST20450 and T425 should be different, otherwise the workarounds >have not been insterted. >>The problem manifests itself in the following piece of the assembly. >>Periodically, the result from gt is equal to the result of the value >>at ?ws-8 xor'd with MINT, instead of 0 or 1. >> >> LDL ?ws-6 >> MINT >> XOR >> LDL ?ws-8 >> MINT >> XOR >> GT >> DUP >> STL ?ws-7 >> CJ @?11 >Ok, wild stab in the dark, and this is not my area of expertise, but >isnt GT a "multicycle ALU function" which follows another ALU operation >(XOR)? If so, there should be a NOP inserted between them. ie > .. > XOR > NOP > GT > .. >Below is an excerpt from the "SGS-THOMSON Microelectronics; ST2450A >Customer Bug List". Ours was given to us by our distributor MMD, was >produced by "ST20 Technical Marketing", and was "Created on: November >18, 1996". There is no date beside the "Last Revised on", so it anyone >knows of a more recent update, I would love to know. >If you dont have a copy of this bug-list, get one - it is essential. >********************************************************************** >* Interrupt of multicycle ALU function causes function to be skipped * >If a micro interrupt occurs in the first cycle of a multi-cycle ALU >operation that immediately follows another ALU operation instruction, >then the instruction will be skipped and not executed. >Software Workaround >------------------- >Place a NOP instruction between the two ALU instructions. This has been >implemented in both our OCCAM and C compilers as a command line option. >Note that the workaround should be included in any hand written >assembler code. >********************************************************************** >>Has anyone else experienced, or heard about, any problems with >>incorrect results from GT? Is anyone else able to reproduce it? >If I understand it correctly then this can happen with any multi-cycle >ALU operation, so add, sub, mul, fmul, div, rem, gt, gtu, prod, satadd, >satsub and satmul should all be affected. >>Here follows the C code for the first test: t1.c. >I dont have access to the latest SGS C Toolset, so would anyone who has >like to confirm my theory by compiling up these programs with D7414A to >see what sort of code is produced? >Thanks, >Mark......... >PS Anyone out there interested in setting up an ST20450 support group >(probably via email) to discuss problems and maybe try to get SGS to do >something about them? >-- >Mark Booth (markb@oxim.demon.co.uk) >-------------------------------------------------- >Oxford Intelligent Machines Ltd, Oxford, UK. >Voice +44 (0) 1865 204881, Fax +44 (0) 1865 204882 Wayne, It looks to me like Mark's analysis is on track. I don't have an errata sheet for the 20450, but that would be a useful first step! I suspect a workable solution for the problem would be to add some rules to the final post-pass optimizer to notice the "illegal" combinations and insert NOP's if compiling for the 20450. It has been a 5 or 10 years since I looked at that code but I think it would be do-able. A more annoying aspect would be going through all the runtime assembly code and fixing the illegal combinations in a library specific to the 20450. Nothing impossible, just aggravating! Whatever happened to debugging silicon? Cheers, Kirk Bailey bailey@oneworld.com Logical Systems PS: The optimizer modification would be somewhat simplified in that not all the "suspect" instructions are generated (unless you have modified it anyway!)