Number: 2167

Date: 12-Sep-84 16':19':12

Submitter: masinter

Source: Maxwell, Kaplan

Subject: BREAKDOWN of type FIXP doesn''t work because (BOXCOUNT) generates a BOX

Assigned To: 

Attn: Masinter

Status: Open


Problem Type: 

Impact: Moderate

Difficulty: Hard

Frequency: Intermittent

Priority: Perhaps

System: Programming Environment

Subsystem: Performance Tools



Lisp Version: 11-Sep-84 18':48':58

Source Files: 

Microcode Version: 

Memory Size: 

File Server: 

Server Software Version: 

Disposition: '
["masinter" "12-Sep-84 16':22':01"]'
["Sannella.PA" "13-Sep-84 09':38':19" Description':]

Description: From':'
Date': 26-Aug-84 22':37':06 PDT'
Subject': Re': BREAKDOWN of FIXP'
In-reply-to': Your message of 26-Aug-84 14':15':30 PDT'
To': masinter'
cc': KAPLAN'
Yes, it definitely is BRKDWNTYPE=BOXES, not CONSES.  CONSES seem to be OK.  I think it is easily reproducible.  Martin just got another one, where breakdown said that a function defined as'
(LAMBDA (X) (IGEQ X 127))'
was responsible for lots of fixp''s.  This can''t possibly be true, can it?'
In Maxwell''s example, the number of FIXP''s was said to be negative for some number of functions.'
I''ll try to isolate an example, if I can get to it before I take off for the rest of the week.'
From': Masinter'
Subject': AR#2167, BREAKDOWN of type FIXP doesn''t work because (BOXCOUNT) generates a BOX'
To': Maxwell, Kaplan'
cc': LispSupport'
I''ve tracked down the problem you reported that far but am now stuck a bit without a more major overhaul of BREAKDOWN. The problem is that the guy who is counting number boxes generates one, and gives bogus results once the number of number boxes generated gets bigger than 2↑16. I don''t have any great ideas, maybe BOXCOUNT macro could return a (shudder) constant number box?'
Date': 12 Sep 84 17':08 PDT'
Subject': Re': AR#2167, BREAKDOWN of type FIXP doesn''t work because (BOXCOUNT) generates a BOX'
In-reply-to':''s message of 12 Sep 84 16':21 PDT'
How about giving an extra argument to BOXCOUNT, which, if it''s a number box and the new value is large, gets smashed with the new value and returned.'
At least then the caller has control of the constants.  Indeed, BREAKDOWN might be the only user of this non-documented feature.'
In the long run, when we have uboxed, declaration controled FIXP arithmetic, the problem should go away by itself.'


Test Case: 

Edit-By: Sannella.PA

Edit-Date: 13-Sep-84 09':38':19