Re: High Level Language vs Assembly

"Joachim Durchholz" <joachim_d@gmx.de>
10 Mar 2001 15:58:43 -0500

          From comp.compilers

Related articles
[18 earlier articles]
Re: High Level Language vs Assembly ts3@ukc.ac.uk (T.Shackell) (2001-03-08)
Re: High Level Language vs Assembly kszabo@nortelnetworks.com (Kevin Szabo) (2001-03-08)
Re: High Level Language vs Assembly tfjellstrom@home.com (Tom Fjellstrom) (2001-03-10)
Re: High Level Language vs Assembly samiam@cisco.com (Scott Moore) (2001-03-10)
Re: High Level Language vs Assembly bobduff@world.std.com (Robert A Duff) (2001-03-10)
Re: High Level Language vs Assembly mr@peakfive.com (Matt) (2001-03-10)
Re: High Level Language vs Assembly joachim_d@gmx.de (Joachim Durchholz) (2001-03-10)
Re: High Level Language vs Assembly joachim_d@gmx.de (Joachim Durchholz) (2001-03-10)
Re: High Level Language vs Assembly toon@moene.indiv.nluug.nl (Toon Moene) (2001-03-12)
Re: High Level Language vs Assembly ts3@ukc.ac.uk (Tom Shackell) (2001-03-14)
Re: High Level Language vs Assembly jthorn@galileo.thp.univie.ac.at (2001-03-14)
Re: High Level Language vs Assembly tfjellstrom@home.com (Tom Fjellstrom) (2001-03-22)
Re: High Level Language vs Assembly anton@mips.complang.tuwien.ac.at (2001-03-22)
| List of all articles for this month |

From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 10 Mar 2001 15:58:43 -0500
Organization: Compilers Central
References: 01-02-094 01-02-101 01-03-015 01-03-036 01-03-049
Keywords: optimize
Posted-Date: 10 Mar 2001 15:58:43 EST

T.Shackell <ts3@ukc.ac.uk> wrote:
> however triangles are parameterized on
>
> - object position
> - object orientation
> - camera position
> - camera orientation
> - current texture (for multiply textured objects)
> - current animation frame (for animated objects)
> - position relative to potentially moving lights
> - orientation relative to potentially moving lights
> - what objects are infront of another (for semi-transparent objects)
> - ... and possibly others
>
> This is a staggering number of possible variations (bearing in mind
> most of these quantities are stored in multiple 32 bit numbers).


True.


But there's still a lot of things that can be improved if code
generation and optimization is moved to the customer's machine.


1. You can generate code for the customer's hardware/driver
combinations.


2. You can inline shared library (DLL) code if the library is used
just once, resulting in better load times and better performance. This
produces opportunities for additional dataflow analysis and further
optimization.


3. You have better control over what to leave open and what to fix
statically, and you can better exploit statical stuff. For example,
assume the program has an intro, a film rendered using the same 3D
engine as used during normal program operation. You could render the
film during software production and compress it using some video
format (QT or AVI or whatever). As an alternative, you can generate
the code during installation time. You can use this flexibility to
adapt the detail level of the film to the customer's hardware. Or to
exploit API details that aren't present on every machine, and where
manual exploitation would be too cumbersome and/or error-prone.


4. You can do code generation during installation time. You'll have to
regenerate the code after hardware and software upgrades that change
things that were exploited during code generation, so the software
should keep a record and check whether anything relevant has changed
at start-up.


Regards,
Joachim


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.