Number: 1994

Date: 28-Aug-84 13':20':07

Submitter: Sannella.PA


Subject: BREAKDOWN depends on misconception about \BOXIPLUS, \BOXIDIFFERENCE

Assigned To: Masinter

Attn: Release

Status: Fixed


Problem Type: Bug

Impact: Serious



Priority: Hopefully

System: Programming Environment

Subsystem: Performance Tools



Lisp Version: 27-Aug-84 21':14':00

Source Files: 

Microcode Version: 5124

Memory Size: 4096

File Server: 

Server Software Version: 

Disposition: '
["Masinter" " 5-Sep-84 13':22':34" Assigned% To': Attn': Status':(Open->Fixed) Machine':(1132->) Description':]

Description: [for release message': should only mention new BREAKDOWN has slightly less overhead/call than old. For least overhead, set BRKDWNCOMPFLG to T (is BRKDWNCOMPFLG documented?]'
Date': 27 Jul 84 18':33 PDT'
Subject': Lisp': ARG NOT ARRAY in BREAKDOWN'
Lisp System Date': 27-Jul-84 18':22':08'
Machine': Dorado (Ahwahnee)'
Microcode version': 24,4'
Memory size': 10000'
Frequency': Always'
Impact': Serious'
When I breakdown a function with 2 measurements, it compiles the compound measurement function and then gives a break ARG NOT ARRAY inside SETA inside BRKDWNCLEAR.  Looks like the offending argument is an arrayblock instead of an array.'
This is new in this loadup, I think.'
Date': 29 JUL 84 20':33 PDT'
Subject': breakdown'
To':   kaplan'
cc':   lispsupport'
I went into breakdown to fix a bug, and wound up trying to make it run faster. In the meanwhile, I may have broken it, too.... I''ve been meaning to test it but didn''t have the time.'
Apparently I did break it... it will have to wait til my return unless you wanna look at it.'
Date':  1 Aug 84 15':29 PDT'
Subject': Lisp': BREAKDOWN problem'
To': Masinter,'
I looked into the BREAKDOWN problem a bit, and here is what I''ve discovered.'
The original symptom I reported was due to only partial compilation with what seem to be new macros.  When I BCOMPL''ed the file, that problem (bad arg to SETA under BREAKDOWNCLEAR) went away.'
However, the current (i.e., Larry''s new, optimized) implementation seems to depend on a fundamental misconception about \BOXIPLUS, \BOXIDIFFERENCE, etc.'
The breakdown code assumes that those functions take pointers to arbitrary storage locations, and treat those as if they contained the bits of a 32-bit integer.  Thus, it is passing in pointers to the middle of an array block.'
But those functions explicitly test to make sure that their first argument is a FIXP':  (\DTEST X ''FIXP).   This immediately gives rise to a non-numeric arg error.'
I don''t see an easy way of fixing this without producing new versions of \BOXIPLUS etc that work on arbitrary pointers, or consing up a fixp via \GETBASEFIXP or whatever, thereby causing fixps to be allocated all over the place.  Fast unboxed arithmetic code would also solve the problem.'
I don''t think its worth my reworking all this when in fact Larry might already have a clear view of the solution.  I guess this will have to wait until Larry returns.  '


Test Case: 

Edit-By: Masinter

Edit-Date:  5-Sep-84 13':22':37