Re: Control Flow Stack deficiencies

John Passaniti <nntp@xxxxxxxxxxxxxxxxx> wrote:
Andrew Haley wrote:
Not in Borland Pascal compilers (which compiled straight to native
code).

How bizarre. There is little excuse for that, given the ubiquity
of the P-code compilers and the way that Wirth implies the use of
a jump table with "although the efficiency of the case statement
depends on its implementation, the general rule is to use it when
one has several mutually exclusive statements with a similar
probability of selection."

It's bizarre that the authors of a Pascal compiler that generated
native code (not p-code) would consider the use of code generation
and optimization strategies specific to native code?

I did not say that it's bizarre that the authors of a Pascal compiler
that generated native code (not p-code) would consider the use of code
generation and optimization strategies specific to native code, and
neither did I say anything that might have implied it.

There's nothing about failing *ever* to use a jump table that's
specific to the generation of native code.

My memory of Apple Pascal (which was based on the UCSD p-System) was
that it did indeed have an opcode (XJP, if I remember correctly)
that was used with case statements-- but not exclusively. The
opcode required four arguments (minimum index, maximum index, a jump
past the end of the table (when the index wasn't in range), and the
table itself. If the compiler found that it was more efficient to
use another structure, it did.

Jump tables didn't make sense when the case selectors were sparse:

var i: integer;

case i of
1: something;
2147483647: another_thing;
end

And they didn't make sense when there were large ranges:

case i of
1..1000000: something;
end

Sure, we both know that. I made precisely such a point in
<2bWdnd4tWJk2VbDVnZ2dnUVZ8szinZ2d@xxxxxxxxxxxxx> a few weeks ago.

What exactly is your point? I was saying that there is little excuse
for failing ever to use an indexed jump when generating a code for a
switch.

Andrew.
.

Relevant Pages

  • Re: Native Code vs PCode
    ... > a disagreement over the term "interpret". ... > how this p-code is executed. ... > form of run-time translation of p-code to native code, ... There is no JIT compiler ...
    (microsoft.public.vb.general.discussion)
  • Re: Native Code vs PCode
    ... Subject: Re: Native Code vs PCode ... VB's version of P-Code is MS's own highly optimized proprietary ... > In effect the 'interpretation' or 'translation' has already been done at ... There is no JIT compiler involved. ...
    (microsoft.public.vb.general.discussion)
  • Re: OT:aside to Bob - learning Pascal?
    ... the DG used 'P-Code' but then it was 'Pseudo' ... If not the actual technology - then the term. ... It is possible that the 'native code' compiler in VB is not very ...
    (microsoft.public.vb.general.discussion)
  • Re: How did C++ beat the competition?
    ... Microsoft's first C++ compiler, 7.0, actually generated a form of p-code that ... also generate native code and mix native code and p-code in a single ... so Microsoft simply stopped talking about it. ...
    (comp.lang.cpp)
  • Re: NatiVe Code or P Code question
    ... >> It's nice to have the native code option, but truth is I've seen very ... the P-code is sensitive to changes in the interpreter subsystem. ... been the result of an 'interpretation stage' of the 'runtime' of older ... Most differences between PCode and Native Code will be based on ...
    (microsoft.public.vb.general.discussion)
Loading