HP 64000 using 6800 Pascal Cross Compiler

Holly,

Why do you want the source code? If you have the library, you can link it in and everything should work.

The source is long since gone. That compiler was released in ~1981 and has been off the price list for a long time. Any archives are long gone. I was an Apps Engineer supporting emulators for HP. Until very recently I had copies of the last version of every HP 64000 series product, including emulators, compilers, assemblers, etc. I didn't destroy any of it. I gave it away to a consultant who has the tools and ability to make copies of any of it, for a price. With a little work, it would be possible to disassemble anything that you might need.

Contact Tony Karavidas (sp?) at snipped-for-privacy@encoreelectronics.com. He's a good guy.

I would also like to have the source for this library, although I may be able to disassemble it.

The idea is to move from the HP350 computer with the HP64000 cross compiler on it to a Windows platform and use GNU to cross-compile it.

I have converted some of our assembly files and some of our C files but I have no solution to translate Pascal files (140,000 lines) to C. If I would have a translator I can compile C using the GNU cross-compiler for 68020.

I have the Pascal/64000 document (manual part 64800-90909) on paper, might you have that one as scanned-in document? Then I can send it to a company (Micro-Processor Services, Inc.) that might translate Pascal to C.

Would contacting Tony Karavidas be a good idea?

thanks in advance,

Harm Salomons

Please note that GCC (the 'GNU compiler collection') already includes a Pascal compiler. It may not be part of the readily built cross-compiler package you're using, but you shouldn't let that stop you. Building your own GCC cross compilation toolchain is harder than just using a prebuilt binary, sure, but it's not rocket science.

... snip ...

Why do any of that? Virtually anywhere you can use GNU C you can use GNU Pascal, which is fundamentally a different front end for gcc. Look up gpc.

P2C knows almost all the dialects of Pascal I'm familiar with HP, Apollo, ISO, and it's also from the Free Software Foundation.

When I were to use the pascal compiler of GNU then I would have to deal with some specials in the current cross-compiler. It has extensions like a user defined type, it also has compiler directives to turn a subroutine call into a trap.

Also I do not want to adapt the sources to the pascal compiler because during the transition between the current environment and a future environment on a PC I need to keep the original sources as they are, to compare the results.

I do not intend to spend time in changing the GNU pascal compiler although that sounds as an interesting experience.

H. Salomons

Thank you for pointing out this site. I tried to translate our Pascal with it, but this is not easy. It complains about 'UNSIGNED_32' types, which are built-in into the cross-compiler. Also it does not recognize function calls. I will have to look some longer to it...

As I pointed out, our Pascal does not match standard pascal. I tried gpc and p2c. The move to C is for better portability.

You can't just use a good text editor on the Pascal source?

Some definitions and the C preprocessor will handle a lot of the differences.

#define begin { #define end } etc.

I am afraid that the problem is more complex than you can solve with macros. How would you deal with the WITH statement, where you can copy items from one record to another record:

WITH REC_A, REC_B TAG_A := TAG_B;

you will know that TAG_A is a part of REC_A and TAG_B is part of REC_B, a macro can never have that knowledge, a compiler must.

This I don't believe. There must be something else going on that's preventing the function calls from being recognized.

I had a similar problem some time back with converting from the Stratus 'C' dialect to HP's 'C' dialet. It may be more difficult than just running sed on the source, I had to use yacc/lex to identify the correct grammatical units and perform the code conversions. I don't think you're going to find anything that doesn't require some effort to adapt to your situation. I recommend the bison route only as a last resort, it is a major PITA.

I downloaded a summary of HP64000 Pascal. It looks to be fairly standard Pascal with a few added pre-defined types. Is there any reasaon why you can't create a module defining these types that you can include in every file? Are there any other non-standard language features preventing you from using p2c or gpc (like the function thing you mentioned)?

CB

It may be instructive to see how a Pascal compiler handles this. The with statement opens another scope of identifiers, in which all the identifiers of REC_A, and then of REC_B are added to the previous scope, possibly shadowing some previously viable values. The addressing of the variables is an offset from that of the records proper. The sequencing of REC_A, then REC_B, allows for REC_B being a field of REC_A rather than independant.

Now compilation continues normally until the conclusion of the with statement, when that new scope is exited, and identifiers return to using the previous scope.

I've done some more checking and the sources are long gone. You probably don't need them, though. If you were to compile your code with another compiler, then the calls would certainly be different. Those 'internal' libraries were written for specific operations and were used like macros.

Good luck. I've known other people who tried to port 64000 Pascal to other Pascal dialects, but I have not heard of any successes. Of course, that was so long ago, I might have forgotten.

There was some work on a Pascal to C converter some years ago, but it only did 'pure' Pascal and choked on the 64000 extensions.

Because that manual was written, and the product obsoleted, before the march to Acrobat format began, it never made it into .pdf. I don't think I have a hardcopy anywhere, but I'll look.

He might have some stuff that I don't have, so it wouldn't hurt. He might also have the time/energy to scan the manual for you. I'd do it, for a fee, but I'm much more expensive than Tony is.

Hello Al,

Thanks for your input on the subject. I admit that we are way too late, but if you would know everything in advance you would not be doing the work that you are doing now.

For the manual: do not bother, the company that is willing to try to translate the Pascal has a copy of it.

At the moment it is not sure that we are really going to port. Even if we have a working Pascal translator we are still left with 'minor' problem (isn't that an understatement?) that our Assembler sources were written to use D7 to return the integer or long result of a function while GNU uses D0. And that is the most obvious problem.

For the moment it looks like the best solution to have at least two development systems available: if one breaks down, the other is still available.

Good luck everybody with your cross-compiers problems,

signing off,

H. Salomons

Hello Craig,

I have let loose a 'bison' and 'flex' on our Pascal sources, after stripping the files of the compiler directives. It immediately breaks down on the order that was in the file:

CONST ...

TYPE ...

CONST ...

That means that the BNF that was used was too 'pure'. With the documentation at hand I should be able to create a BNF that better fits the Pascal. But all these things take time and I know too little about this area. I would prefer to have it done.

Thanks again for your input,

H. Salomons

Just a small observation. Translating a program from one language to another because you can't get a few items to work in the original language is like setting yourself on fire because you are cold.

I.e., if you can't work out your problems in the original language, translating it will only make it worse.

Hello Scott,

the reason to translate is that the platform on which we do the development is getting old and is no longer supported. On that platform we use for the greater part Pascal as language. As you read from the discussion, Pascal is not so portable, so if you want to port to for instance a PC as cross compiler platform, better use C as a language. The Pascal program itself does the job that it was meant to do.

H.Salomons

Pascal is actually much more portable than is C. In the past the problem has been availabilty of compilers for various platforms. With the present method of having gcc contain separate front ends for languages and back ends for compilers, that C advantage has been overcome.

To illustrate the extra portability, Pascal does not demand a binary number system, nor a hierarchy of integer types. Instead it requires a value MAXINT, and allows anything else to be arbitrarily specified as a subrange of integer. The generic SET construct does anything that C bitpicking can do, but in a completely portable manner. In addition Pascal is virtually error-free when compared to C, largely due to the combination of ranges, range checking, and absence of pointer arithmetic.

"CBFalconer" wrote

Hmpff. We used an h/p 64000/Pascal/NSC800(Z80) some 15 years ago.

All array address calculations were done as 32 bit values. For a 4-byte array on an 8-bit machine this was a gas. Couldn't figure out at first what in *&^%$'s name was making the CPU run so slow (not that it ever ran fast). For greater portability I imagine

I remember doing lots of this. Looked like C when I was done...

That it is. The difference is really stunning. Anybody remember the April issue of Computer language c.1985(?) and the article on the beginnings of C and Unix? Ah, found it:

I had a problem (of my own creation) and called h/p support. The man at the support desk was rather surprised:

"Pascal? Wow, all the calls we get are about C."

I should have asked him if he had heard the one about the Maytag repairman.*