HP OpenVMS Systems

ask the wizard
Content starts here

Native TECO for OpenVMS Alpha?

» close window

The Question is:

 
TECO native mode on Alpha?
Any chance to convince andy (ACG) to recompile TECO32_TV into native alpha
code so it does
work with all alphas in the future and while
being on it to enlarge the q-registers (still
limited to 128 vax pages)?
Asking for TECO/FTP might be too much and would ruin the future of some unix
cracks...
 
 


The Answer is :

 
  This is viewed as highly unlikely, unless the local OpenVMS management
  chain dozes off for an unusually long interval -- and doesn't notice
  the sudden activity in this area and the sudden inactivity in other
  (expected, currently scheduled) projects.
 
  The central problem with a properly-compiled native TECO is that the
  current version is written in absolutely awful spaghetti Macro32.
 
  Please recall that the lineage of the TECO source base is roughly:
 
    Original implementation on PDP-1 in 1963 by Dan Murphy
    Ported to PDP-6/PDP-10
    Ported to PDP-8
    Ported to PDP-11
    Ported to VAX
    VESTed to Alpha
 
  Each one of those ports was done in a mechanical or semi-mechanical
  manner, so the current VAX Macro32 code is really, really bad. It would
  be far less effort to just rewrite Teco in C than fixing up the Macro32
  so that the Alpha Macro32 compiler would accept it.
 
  Please understand that TECO32_TV really is native Alpha code -- though
  roughly one-quarter as efficient as you would receive from (say) the
  C compiler.  VEST really is a compiler, albeit a rather strange one.
  Its source language is the VAX binary instruction stream; out of that
  it compiles the equivalent Alpha code. TECO is not running in emulation,
  nor do Alphas have any special hardware for VAX emulation, like the old
  PDP-11 compatibility mode on the VAX which went away with later models.
 
  TECO32_TV should work on all Alpha systems; if it breaks on any future
  model, please contact Compaq support.
 
  As for the 128 VAX page limit -- there shouldn't be anything in the
  current implementation that inherently imposes such a limitation.
  It's just left over from the PDP-11 implementation and (so far) little
  demand to extend it.
 

answer written or last revised on ( 3-JAN-2000 )

» close window