home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.misc
- Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
- From: hrubin@pop.stat.purdue.edu (Herman Rubin)
- Subject: Re: languages which allow the introduction of new operators
- Message-ID: <Bxz8px.FBx@mentor.cc.purdue.edu>
- Sender: news@mentor.cc.purdue.edu (USENET News)
- Organization: Purdue University Statistics Department
- References: <1992Nov15.032459.3069@udel.edu> <Bxr9vx.KBD@mentor.cc.purdue.edu> <1992Nov18.154754.1848@udel.edu>
- Date: Thu, 19 Nov 1992 18:58:43 GMT
- Lines: 60
-
- In article <1992Nov18.154754.1848@udel.edu> carroll@dori.cis.udel.edu (Mark C. Carroll) writes:
- >In article <Bxr9vx.KBD@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
- >]In article <1992Nov15.032459.3069@udel.edu> carroll@thorin.cis.udel.edu (Mark C. Carroll) writes:
- >]]In article <BxMCxA.3nM@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
-
- .......................
-
- >Any optimization, particularly on modern architectures, has got to
- >consider its affect on pipeline fills, branch predictions, register
- >allocations, memory and cache uses, and dozens of other factors. Do
- >you think that you're qualified to judge what affect your two-cycle
- >savings will have on the rest of your program? If so, you're in the
- >wrong field - you should be designing compilers.
-
- I am quite aware of all of these. In most of the cases I have discussed
- in any detail, I can see ways that the language design prohibits many of
- these considerations.
-
- As to designing compilers, this is a massive operation, not to be done by
- one or two people. And when it comes to optimization, these compiler
- designers should ask for things to be considered which they do not now
- consider. This applies to language design, as well. The people who
- seem to dominate the field assume that their considerations are ALL
- that matter.
-
- >]The semantic model of the language can, however, greatly inhibit the
- >]programmer. Try communicating floating binary from one machine to
- >]another; the only semi-portable way I have seen are to convert to
- >]higher precision floating decimal, transmit that, and convert back.
-
- >What does that have to do with the semantic model of the language?
- >That's a very hardware related issue. If I design a language that uses
- >floating point numbers, I'm restricted to using whatever internal
- >float format the hardware designer chose for the architecture I'm
- >learning. That's got nothing to do with the semantic model of the
- >language.
-
- Did I say anything about matching the internal representations of
- the numbers? We can communicate binary integers across machines
- and implementations; the much used notation 0ddddd for octal and
- 0xdddddddd for hexadecimal, bad as they are, do this explicitly.
- Algol had a different way to do this, and it could handle other
- bases explicitly; I believe it could also do this for non-integers,
- but the syntax did not carry over well. Most languages and
- compilers allow for explicit writing of fixed-point decimals
- and floating-point decimals. However, there are many situations
- in which people may wish to communicate non-integers in hex. I
- have found cases in which decimal is inconvenient and even leads
- to confusion.
-
- I have seen the problem addressed by coming up with a characterization
- of the number of decimal digits which need to be communicated so that
- a given number of bits are correctly communicated by conversion. This
- I do not find to be satisfactory, and I see no reason why this insistence
- on decimal as the only means of communication is made.
- --
- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
- Phone: (317)494-6054
- hrubin@snap.stat.purdue.edu (Internet, bitnet)
- {purdue,pur-ee}!snap.stat!hrubin(UUCP)
-