Conference turris::languages

    Not that I know of.  Your best bet would be to look in the designated
    operating system conferences such as RT or RSX.  There is however an
    excellent self-paced course book available EY-DC066-PS-001.  Bedford
    should have it. 
    
    Too bad that some people do not consider MACRO-11 even a language :-)
    I am always glad to see one more person wanting to learn MACRO-11. I
    know you will enjoy it.
    
    - Vikas 

	I was hoping this note might turn up a MACRO notesfile as well so
    that I could invite all those MACRO programmers to join in on the "Battle
    of the Languages", but it seems that Robert Praetorius has already entered
    a MACRO program (see note 99.42), so I guess they must make the rounds of
    some of the other notesfiles instead!

	Just as a side note, I have another idea brewing which will be coming
    out in a couple of weeks and which will allow the MACRO programmers, as
    well as the the MICRO-CODE programmers to get in on all of the fun here.
    Because I'll be collaborating on this idea with someone, the idea will be
    placed on the back-burner for a couple of weeks while my partner gets
    everything organized, etc.  So, stay tuned for this notesfile for further
    developments.

								-davo

    You might note that the LIFE program which Robert P. entered was
    in MACRO-10/20, NOT MACRO-11.  (There's a slight difference :-)
    I might also note that MACRO-32 is different from MACRO-11.
    I remember interviewing a job candidate at DEC once.  On his resum�
    under "languages", he had written ASSEMBLER.  When I asked him which
    "assembler", he was amazed that there was more than one!
    After noticing Peter Vatne's TECO program to play life in the "battle",
    I must point out that TECO programs are generally known as MACROs
    too :-).
    
    I did write a MACRO-11 program to play LIFE on a DEC GT-40 vector
    graphics tube once, but it's long gone.

re: .3,

	Thanks for clearing this up, I'd probably finally get around to
    installing compatability mode on the queue cluster {JUNIPR,MRSVAX}
    only to discover I need a 10-20 to compile entry #13.

	I'll try to ammend the Current Program Entries reply to fix this.

							-davo

    What? You mean your VAX doesn't have DEC-10 compatibility mode?
    All you need is the 4_extra_bits option :-)
    
    Gee, the DEC-20s named GIDNEY/CLOYD/MRFORT use JUNIPR as a print
    server.
    Maybe you could use G/C/R as a compute server for this problem?
    
    Sorry, I couldn't resist.
    

Hmmm,

	Maybe I'll check into this possibility.  In the meantime, has anyone
    else actually compiled/run this program?

							-davo

re: .-2

     I'm sure everyone recalls that IBM emulated their 36 bit hardware (7000
series) on their 32 bit hardware (360 series) in microcode.  They even claimed
equivalent or better performance for the high end 360 in 7094 emulation mode
than for the 7094 itself.  It would be interesting to see how the datapaths and
microcode were organized to accomodate this sorta thing.

     Of course, someone emulating a 10 on a VAX would be faced not only with the
problem of the VAX coming up 4 bits shy wordwise but with the problem of the
10's architecture having a larger address space, which wasn't a problem with the
7094 emulation on the 360.
							irrelevant as ever,

							       RP

< Note 100.7 by VAXWRK::PRAETORIUS "US out of Massachusetts!" >

  Of course, someone emulating a 10 on a VAX would be faced ... with the
  problem of the 10's architecture having a larger address space ... 

Huh? The -10 has a 18 bit address space, and with extended addressing you
get 22(23?) bits in user mode. The hardware and/or software was never designed
to handle 36 bits of address. I think you are confused!

VAX'es have 32 bit address space >> 22 bits!

The extended addressing architecture allows direct addressing of 2**30
words of virtual memory, or at least 5*2**30 > 2**32 7 bit characters.

The KL processor only implements a 23 bit virtual address.  However, the
last I heard, it was a goal of Systems Concepts' SC-30M Mars-I processor to
support the full virtual address space.

The Fortran-20 compiler should generate correct code for 30 bit virtual
addresses with the change of one assembly parameter used to check for bogus
array dimensions.  FOROTS, the runtime system, would support up to 27 bit
virtual addresses if one feature test switch is changed.  I suspect it
would easily support even larger core images once Tops-20 was changed to
support larger virtual addresses for system calls which require page
numbers larger than 18 bits.
				/AHM