[Info-vax] Whither VMS?

[VAXman- at SendSpamHere.ORG]

In article <7irr0kF332b3gU1 at mid.individual.net>, billg999 at cs.uofs.edu (Bill Gunshannon) writes:
>In article <00A9285E.A191C0B4 at sendspamhere.org>,
>	VAXman-  @SendSpamHere.ORG writes:
>> In article <7irif8F31nq9iU12 at mid.individual.net>, Bob Eager <rde42 at spamcop.net> writes:
>>>On Sun, 04 Oct 2009 11:17:17 +0000, Bill Gunshannon wrote:
>>>
>>>>> Macro is an assembly language on steroids.  Bliss is an assembly
>>>>> language on steroids.  C needs Altoids, not steroids, because it
>>>>> stinks.  It doesn't even have a decent macro capability.
>>>> 
>>>> Because C came from the Unix environment and putting the Macro
>>>> Pre-preocessor in the compiler would have violated the paradigm Unix was
>>>> based on.  Thus, "cpp" and, of course, M4 as separate programs.
>>>
>>>It was also necessary for space reasons. The amount of address space 
>>>available on a PDP-11 with non-separate I/D space was only 64K. Of that, 
>>>8K (one page register) was set aside (AFAIR) for system communication, 
>>>leaving 56K for programs.
>>>
>>>c0 (the preprocessor) handled macros and includes. c1 was the compiler, 
>>>which generated dreadful code as there was no space for the code 
>>>generator to do optimisation. c2 was the optimiser, which did a lot of 
>>>clever stuff. I think c1 was the limiting factor, needing pretty well all 
>>>the available address space for program, and data structures.
>>>
>>>Just took a look - c1 was 15K, c1 was 21K, and c2 was 8K (approx). That's 
>>>just code and static data. c1 would need a lot of dynamically allocated 
>>>storage for symbol tables, parse trees, etc.
>> 
>> If you haven't taken notice, C isn't being used these days for PDP-11
>> programming.
> 
>Which, of course, doesn't change the Unix paradigm.  Although GNU is
>trying very hard to break even that.  Of course, when MS puts everything,
>including the kitchen sink, in a single program it is called bloatware
>and when GNU does it, it is called progress. 

Let's take a look at this...

Here, from my Alpha, is a listing of the size of the Macro32 compiler and
Macro64 assembler -- both which possess powerful macro capabilities.

ALPHA_MACRO.EXE;1       9088
MACRO64.EXE;1           5956

Here, from my Alpha, is a listing of the size of the Bliss32 compiler and
Bliss63 compiler -- both which possess powerful macro capabilities

BLISS32EN.EXE;1         9817
BLISS64EN.EXE;1         9807

Here, from my Alpha, is a listing of the size of the DECC compiler which
has pretty sucky macro capabilities.

DECC$COMPILER.EXE;1    11218

Why can Macro and Bliss have powerful macro processors in less space than
the glorified string substitution/replacement preprocessor of C???

I have, for example, a Macro32 macro I've created called: .SSINTERCEPT

        .MACRO  .SSINTERCEPT,func,srvc,type,mode,?lbl1,?lbl2
        ;++
        ; Parameters:
        ;       func: INSTALL intercept or RESTORE system service
        ;       srvc: system service to be intercepted SYS{$srvc}
        ;       type: CHM (CHange Mode) or MOC (Mode Of Caller)
        ;             SYMVEC (on IA64 ONLY)
        ;       mode: KERNEL or EXEC (required for type CHM)
        ;
        ; Implied Parameter:
        ;       name: root system service to be intercepted SYS${name}
        ; ...
        ;--

and it is invoked as:

        .SSINTERCEPT  INSTALL,$chm_mumble,CHM,KERNEL
        .SSINTERCEPT  INSTALL,$moc_mumble,MOC

Try to do something complex like the above in a C macro.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"