[fpc-devel] Dangerous optimization in CASE..OF

[Mark Morgan Lloyd]

On 04/10/17 08:15, Martok wrote:
> Hi all,
> another few months, and something funny happened this morning: a tweet shows upin my timeline which links to this article on efficient codegen for dispatchwith switch statements:<http://www.cipht.net/2017/10/03/are-jump-tables-always-fastest.html>Very interesting!
> Why I'm resurrecting this thread is the reference to Arthur Sale's 1981 paper"The Implementation of Case Statements in Pascal". He compares linear lists,jumptables, binary search and masksearch (on B6700 machines). The bit onjumptables (journal-page 933) contains this part:"""The jump-table itself consists of half-word (3 bytes) unconditional branches,and must be half-word synchronized. The range-check and indexed branch add up to23 bytes of instructions on the assumption that the range limit values arefitted into 8-bit literals, and there is a 0-2 byte padding required to achievejump-table synchronization. *The range check is never omitted as theconsequences of a wild branch which lands outside the jump-table are potentiallydisastrous.* If the range is r, the space requirements are therefore [...]"""
> "potentially disastrous" probably didn't mean security as much as "my room-sizedmainframe crashes", but the point stands...

I've eyeballed that but don't have time to give it the attention it 
deserves. I'd remind you that some of the Pascal implementations for the 
Burroughs systems relied on using the tagged architecture in 
non-standards ways which might have needed the compiler to be "blessed" 
to a privileged state. In general the B6700 etc. was more resilient than 
the earlier B5500, which had the serious flaw that it had "character 
mode" operations which worked on absolute addresses and completely 
bypassed the descriptor-based protection mechanism.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]