Re: High Level Language vs Assembly

"T.Shackell" wrote:


> Scott Moore <samiam@cisco.com> wrote:
>
> > And interestingly, the next level of performance optimization is to go
> > back to high level language, that is, using "online" compilation. The


>
> Intresting I haven't heard of using this style of autogenerated code
> for this. So the idea is you generate a section of machine code for a
> complete 3D object? However I do not follow your logic.
>


I used the technique and saw others use variations of it. In the
press, I finally saw a desciption of its being used in some of
Microsoft's video drivers. As usual, they implied they invented it :)


I first used it for a company that was performing limited video
pattern matching. The job was to take a vector of video bits in an
arbitrary direction (confined to 45 degree increments). The processor
was Z80 (ok, it was a long time ago). They used a hardware processor
to gather and match the bits. Since the video 256x256 bit image was
memory mapped, I reallized that the ideal would be to generate a
series of bit test instructions using the ix/iy pointer offset
instructions to move in 2d, and count the bits that match. Because the
hardware implementation had to share the buffer with the CPU and had
wait state limitations, I was able to beat the hardware processor,
which got a few folks upset.


A more common use I have these days is that when I do CLI stuff and
speed of execution is at all important, I generate a series of
instructions into a buffer to execute the command line. This is sort
of a single line to machine language compiler. This is a good example
of why that compiler construction course was not wasted.


> The vast majority of the time cost for a realtime 3D engine is in the
> rasterizer. A hand coded assembler 'any triangle' rasterizer can
> always beat a compiler generated one. The only way autogenerated code
> can win out is to autogenerate code for a specific triangle as apposed
> to a general one (I think this is what you're saying?). however
> triangles are parameterized on


Well, take a line. You can generate a bit by bit set of a line into a
memory mapped buffer. It would be huge. But if you had to generate a
graphical series and use it over and over it would make sense. If you
are talking about general figures, generated code would be more
efficient, but would rapidly get astronomical in size, and with the
state if hardware accelerators, makes no sense.


I would say the threshold of where online code construction becomes
useful is where a custom thing has to be done at a very high
repetition rate. If the thing done is standard, then standard code can
handle it. Online code generation, after all, is just deferring the
time at which code is generated to later than compile time, and then
you have fewer resources (no compiler).
--
Scott A. Moore is samiam@cisco.com

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