The ASMPUT Prolog code was for OS/2, and I think it was referred to as something like Prolog/2. But that code was for a predecessor of the current ASMPUT, before it was ported to Windows around 1998, and it seems unlikely that much of the source has been kept. Also, it seems from Google searches that I was wrong about how the ASMPUT Windows source was created, in that the author claims that the code was largely rewritten for the port to Windows; I suspect that the strange style of much of the final source code was more to do with subsequently porting from an older compiler to a newer one, not from Prolog, although another possibility is that the code was being generated by some tool.
The following is quoted from Dave Alcock's page https://planetmvs.com/hlasm/tips.html: > As posted on comp.lang.asm370 on Thu, 18 Feb 1999 09:04:35 GMT by Brian Kenn > of IBM: > There was a brief discussion about the HLASM Program Understanding Tool > late last year, and I thought I ought to correct a few misconceptions about > it. > > I am the current developer for the brand new ASMPUT, which will be > replacing the current OS/2 version very soon now, and which offers the same > functionality for Windows (95/98 and NT). > > The code has been virtually re-written from scratch giving us a single, > integrated application with a (hopefully) easy to use user interface. > > The tool will provide the same sort of graphical analysis of the code flow > in your program, plus in this new version we've included a fairly extensive > code and register flow analysis which will highlight potential bugs in your > code that aren't detected by the assembler. > > For example, say you make a mistake and type "DS H" instead of "DS 0H" > when defining a label. The tool will highlight this letting you know that > you've coded a storage definition in the middle of your code. Of course it > can detect whether you branch around your storage declarations, and will not > flag them. > > There are heaps of other potential errors that are detected, including the > use of registers before they have any values set, unreachable code, bad > operand alignments that the assembler doesn't detect, wild branches to low > memory, and so on... > > Anyway, enough advertising...I just thought the news group might like to > know that the Program Understanding Tool is alive and kicking... If any design documentation had survived, perhaps it would have been possible to identify which files in the ASMPUT source repository were the latest level for the Windows version, and to work out how to build them. However, that didn't happen. I don't remember much about the code myself - I think there should be at least one person still at Hursley who was involved in the attempt to modernise it, and may be able to comment. Jonathan Scott
