[Simh] BLISS ( was Re: 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access))

[Johnny Billquist]

On 2018-01-26 22:49, Timothe Litt wrote:
> 
> On 26-Jan-18 14:45, Paul Koning wrote:
>> ent.​  I also do not know what they are doing with the front-ends.
>> One of the more curious front ends of GEM is the Alpha assembler.  I found out about that when doing some Alpha hand-optimizing early on (a handcoded "memcpy with TCP checksum calculation while doing it" if I remember right).  It turned out I could write drafts of that code and give it to the assembler with a /OPTIMIZE switch to let the back end take what I wrote and do stuff to it.  It wasn't always right, but it was a neat source of ideas.
> Well, not exactly an optimizing assembler.  It sort of looks like one.  
> But the real story is that the Alpha port needed to deal with the large 
> amount of MACRO-32 in VMS.  The solution was to treat MACRO-32 as a 
> compiled language, and generate a GEM front end for it.  There was a lot 
> of optimization that was absolutely required if you wanted tolerable 
> code - e.g. most VAX instructions set condition codes, but they are 
> rarely tested - and when tested, usually only a subset of those set are 
> involved in the test.  So tracking condition code generation and 
> consumption is a big win.  And when you look at address generation, 
> there's a lot of opportunity for CSE elimination, and other 
> optimizations.  Then you wanted to schedule the generated code for Alpha 
> - which is a lot of re-ordering, packing & the like.
> 
> Then it was extended for the Alpha instruction set (psect attributes, 
> instructions, etc).
> 
> At this point, you have a compiler for low level language, that happens 
> to look like assembler.  Externally, perhaps a distinction without a 
> difference; internally, quite different.  And if you're unlucky enough 
> to have to do instruction level debug, very different from traditional 
> assembler.
> 
> There also was the argument that you really couldn't (well, shouldn't) 
> write pure assembler for Alpha because the best scheduling depends on 
> the implementation (how many execution units, of what sorts & latencies; 
> predictions, speculations, prefetch; etc.)
> 
> PALcode has some unique constraints that do require manual scheduling, 
> as do some diagnostics.  But it does turn out to be true that Alpha 
> assembler is best understood (and used) as a low-level compiled 
> language, not an assembler.

Are we talking about MACRO-32 or Alpha assembler now? They are two 
different things. PALcode, I would assume, you actually wanted an Alpha 
assembler for. Porting lots of VMS stuff needed the MACRO-32 compiler. 
Exactly what Paul was doing, and in which language, was a bit unclear to 
me. I was assuming he was talking about Alpha assembler, and not 
MACRO-32, but I could be wrong.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol