> On Jan 26, 2018, at 4:59 PM, Johnny Billquist <[email protected]> wrote:
>
> On 2018-01-26 22:49, Timothe Litt wrote:
>> ...
>> 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.
Yes, native Alpha assembler. Obviously that is machine dependent if you're
optimizing very seriously. The purpose of the exercise was to see if you could
do TCP checksum in software while moving network data between the Ethernet NIC
buffers and other places, at the same speed as a simple memcpy. The answer is
yes: if you're at all careful, you can do the necessary arithmetic at times
when the CPU would otherwise have been waiting for memory accesses. The same
tends to be true for simple data processing actions on buffers in many other
machines, for that matter. Many years later I did RAID-5 and RAID-6 (XOR
based) in software in a similar way, the cost was simply that of passing over
the memory buffers and the arithmetic involved had an effective cost of zero.
paul
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
