Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 8650s, was Re: Some more patches for GCC on NetBSD/VAX coming soon...



Thanks, that's very good to know. The interesting thing about the older VAXen is not that they have the additional instructions that were removed from the MicroVAX, because I think the "octaword" and H_Float features were always so slow that nobody used them much in compilers. At any rate, GCC never generates any code that wouldn't work on all VAX models and I don't see a reason to change that.

The more interesting question is how the timings of the instructions differ between models. That's what I want to figure out through testing. What I suspect, but don't know for certain, is that the older models benefit more from the hacks to save one byte or save one cycle at the cost of an extra byte, and have a wider variation of cost between instructions. From what I can tell from reading about the newer CPUs, they have more pipelining, so the big benefits are from using small constants (0-63) or registers as operands as much as possible, which I believe the backend already tries to do, and possibly (I need to test this) from aligning jump targets and loops to 4 bytes. You can test this yourself by adding "-falign-loops=4 -falign-jumps=4". It doesn't seem to make the code much bigger. You can also try "-falign-functions=4" although I'm not sure if that helps either.

I'll work on adding a table for the different CPU variants and then copy the values that are there now for the CPUs that the comments say they apply to. Then I'll make a test program to see how many cycles the different variants actually take, and we can run it on actual machines to see how they perform. Then we can use some generic values for the default to generate good code for all VAXen (that's why I was curious if people do use the older ones, which is good because I can get timing values from you!), and then I can add an "-mtune=cvax" or "-mtune=nvax" option to optimize for the exact tradeoffs of that particular CPU regarding choice of opcodes or alignment of labels.

In theory, you could have an "-mtune=simh" but that might be too difficult of a target considering how dependent it is on what compiler & CPU and settings were used to build and run the simulator. But perhaps a generic tuning for "SimH on 64-bit x86" would be possible.

Regards,
Jake


> On Mar 30, 2016, at 10:45, Dave McGuire <mcguire%neurotica.com@localhost> wrote:
> 
> On 03/30/2016 09:17 AM, Johnny Billquist wrote:
>> And I suspect I might be the only remaining person keeping an 8650 alive
>> and running, so I can understand if it's not the default target, but
>> please keep it as an option to target these older machines as well. (I
>> have all instructions implemented in the hardware... :-) )
> 
>  On this note, if you point me toward an 8650 (or any other large VAX)
> I'll happily grab it and run it, at least periodically, at the Large
> Scale Systems Museum. B-)
> 
>                -Dave
> 
> -- 
> Dave McGuire, AK4HZ
> New Kensington, PA



Home | Main Index | Thread Index | Old Index