Number: 825 Date: 24-Apr-84 15':49':49 Submitter: Sannella.PA Source: stansbury.pa Subject: Compiled \BLT returns 0; should return 1st arg as when interpreted Assigned To: Attn: Status: Fixed In/By: Problem Type: Design - Impl Impact: Annoying Difficulty: Easy Frequency: Everytime Priority: Perhaps System: Language Support Subsystem: Microcode Machine: 1108 Disk: Lisp Version: Source Files: Microcode Version: Memory Size: File Server: Server Software Version: Disposition: ' ["Sannella.PA" "21-Aug-84 10':20':53" Attn': Status':(Open->Fixed) Description':] Description: ' Date': 20 Apr 84 22':00 PST' From': stansbury.pa' Subject': Lisp': \BLT returns different values when interpreted and compiled' To': LispSupport.pa' cc': stansbury.pa' ' Lisp System Date': 16-Apr-84 12':58':26' Machine': Dandelion (CSLI-2)' Microcode version': 24,4' Memory size': 5777' Frequency': Always' Impact': Fatal ' ' (BLT A B C) interpreted returns A (evaled), but BLT compiled returns 0 (at least on DLion). s.' ' -- Tayloe.' ' -----' ' Date': 22 Apr 84 23':49 PST' From': stansbury.pa' Subject': Re': \BLT' In-reply-to': MASINTER.PA''s message of 20 APR 84 23':01 PST' To': MASINTER.PA' cc': Stansbury.PA, Lispsupport.pa' ' "Um, what was Impact': Fatal about?"' ' Well, it was fatal in my application, because it resulted in an invalid address. Yes, there are a thousand workarounds, but there are two points':' (a) if BLT is going to return anything, 0 seems pretty inappropriate; either NIL or the first arg seem more sensible (and I vastly prefer the latter, both for esthetic reasons and because it would make one of my applications a great deal simpler).' (b) just for the sake of cleanliness, seems like the interpreted & compiled versions of a fn ought to return the same thing.' ' ' -- T.' ' -----' ' Date': 23 Apr 84 09':19 PST' From': JonL.pa' Subject': Re': \BLT' In-reply-to': stansbury.pa''s message of 22 Apr 84 23':49 PST' To': stansbury.pa' cc': CHARNLEY,MASINTER.PA, Lispsupport.pa' ' This seems pretty clearly a DLion ucode bug, since both the Dorado and Dolphin have the BLT opcode returning the first arg.' ' -----' ' From': masinter.pa' Date': 23-Apr-84 22':46':10 PST' Subject': Re': \BLT' In-reply-to': stansbury''s message of 22 Apr 84 23':49 PST' To': stansbury' cc': MASINTER, Lispsupport' ' causing an invalid address is genrally not Fatal. (You usually can Stop or even TelRaid it.) ' ' It might be Serious, but only if it is ''unexpected'', but here you are running code with \BLTs in it interpreted, so ....' ' just trying to avoid Impact inflation.' ' -----' ' From': masinter.pa' Date': 23-Apr-84 22':54':32 PST' Subject': Re': \BLT' In-reply-to': JonL''s message of 23 Apr 84 09':19 PST' To': JonL' cc': stansbury, CHARNLEY,MASINTER, Lispsupport' ' i can fix it so it doesn''t matter what the microcode returns. I''ll take the macro for \BLT and turn it into' ' (PROGN((\OPCODES BLT) x y n) NIL)' and then \BLT will always return NIL.' ' I''d rather do that than complicate DLion microcode unnecessarily. Some opcodes can return ''undeefined'' without any problem, right?' ' -----' ' Date': 23 Apr 84 23':25 PST' From': stansbury.pa' Subject': Re': \BLT' In-reply-to': masinter.pa''s message of 23-Apr-84 22':54':32 PST' To': masinter.pa' cc': JonL.pa, stansbury.pa, CHARNLEY.pa, Lispsupport.pa' ' Yak! Don''t go and make all BLTs return NIL. First arg is far preferable, and if the interpreter, the Dolphin microcode, and the Dorado microcode all return the first arg, then (unless for unknown reasons it''s hard to make the DLion mc return args) it seems preferable to make the DLion mc conform.' ' -- Tayloe.' ' -----' ' Date': 17 Aug 84 14':02':46 PDT (Friday)' From': Charnley.pa' Subject': re': AR#825, \BLT returning 1st arg, etc.' To': Masinter.pa, Sannella.pa' cc': Charnley' ' I changed this to conform with the other microcodes some time ago. Apparently it didn''t get into the AR data-base. Note that the old behavior was NOT different from OpCodes.doc, only different from the other microcodes. And it cost three micro-instructions.' ' ' Workaround: Test Case: Edit-By: Sannella.PA Edit-Date: 21-Aug-84 10':20':56