home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1432 < prev    next >
Encoding:
Internet Message Format  |  1992-08-22  |  2.8 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!mips!darwin.sura.net!jvnc.net!rutgers!faatcrl!iecc!compilers-sender
  2. From: wjw@eb.ele.tue.nl (Willem Jan Withagen)
  3. Newsgroups: comp.compilers
  4. Subject: Re: constant folding at parse time
  5. Keywords: parse, optimize, comment
  6. Message-ID: <92-08-132@comp.compilers>
  7. Date: 21 Aug 92 08:44:59 GMT
  8. References: <92-08-114@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: wjw@eb.ele.tue.nl (Willem Jan Withagen)
  11. Organization: Compilers Central
  12. Lines: 55
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. you write:
  16. => example.  But what about an expression such as "4 + y + 4"?  As I see it,
  17. => a shift-reduce parser following the rule
  18. => 
  19. => expr -> expr + expr
  20. =>       | CONST
  21. =>       | ID
  22.  
  23. And John says:
  24. => [The only approach I've seen is pretty much brute force -- when you have a
  25. => subtree with multiple instances of an associative operator, flatten the
  26. => tree into a list, sort the list to put all the constants together,
  27. => collapse the constants, and remake a tree.  It is my dim recollection that
  28. => the Ritchie PDP-11 compiler actually did this, because you can get
  29. => significant savings in some kinds of addressing expressions. -John]
  30.  
  31. Now I don't want to open another tarpit again, but this certainly is going
  32. to have effects on the semantics of the used program. When it is only
  33. applied to address calculation which comes from arrays, ... then the user
  34. would not always have to find out. But what about:
  35.     y := maxint-1;
  36.     ...... (nothing for y)
  37.     x := maxint-y+10;
  38. This might or might not give the correct results.
  39.  
  40. And it gets even more tricky when the user has used ()'s to make shure that
  41. thing were done in the proper order. 
  42.   - Do we then annotate the intermediate code that it should not be 
  43.     reorganised? 
  44.   - Or do we only reorganise when we can show that there is no
  45.     danger?
  46.     And how do we show this?
  47.   - what about Floating point stuff?
  48.  
  49.     Willem Jan
  50.  
  51. PS: In the compiler I'm doing I've decided to put an IM->IM
  52.     cse-eliminator (as attribute evaluator) which can be applied 
  53.     whenever on the IM-tree.
  54.     These questions arise from the fact that I think that agresive
  55.     actions could do more harm than that they are worth.
  56.  
  57. -- 
  58. Digital Information Systems Group, Room EH 10.35 
  59. Eindhoven University of Technology   
  60. P.O. 513                             Tel: +31-40-473401,Fax: +31-40-448375
  61. 5600 MB Eindhoven                    The Netherlands
  62. Internet:  wjw@eb.ele.tue.nl    
  63. X400:      C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
  64. [This was for integer expressions in C, which traditionally haven't paid
  65. much attention to overflows.  You're right, though, particularly for floating
  66. point expressions users will not appreciate arbitrary rearragement. -John]
  67. -- 
  68. Send compilers articles to compilers@iecc.cambridge.ma.us or
  69. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  70.