HP 64000 using 6800 Pascal Cross Compiler

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.

On Tue, 14 Dec 2004 03:47:22 -0500, HarmSalomons wrote:

> 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...

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

HarmSalomons wrote:
> 
> 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.

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.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Whew, you've got a tough problem, and you've started solving it about 10 
years too late.

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

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.
> 
> 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.

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.
> 
> 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.

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.
> 
> 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.

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.
> 
> Would contacting Tony Karavidas be a good idea?

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.
> 
> thanks in advance,
> 
> Harm Salomons
> 

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

HarmSalomons wrote:
> 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
> 

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.

-- 
Samiam is Scott A. Moore

Personal web site: http:/www.moorecad.com/scott
My electronics engineering consulting site: http://www.moorecad.com
ISO 7185 Standard Pascal web site: http://www.moorecad.com/standardpascal
Classic Basic Games web site: http://www.moorecad.com/classicbasic
The IP Pascal web site, a high performance, highly portable ISO 7185 Pascal
compiler system: http://www.moorecad.com/ippas

Good does not always win. But good is more patient.

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

HarmSalomons wrote:
> 
> 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.

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.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> wrote

> To illustrate the extra portability, Pascal does not demand a
> binary number system, nor a hierarchy of integer types.

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
64 bit addressing calculations would be used now.

> allows anything else to be arbitrarily specified as a subrange 
> of integer.

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

> In addition Pascal is virtually error-free when compared
> to C

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:

http://www.art.net/~hopkins/Don/unix-haters/etc/unix-history.html

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.*

----
* In North America, 'Maytag' is a brand of washing machine well
  known for its reliability.  Their television advertisements 
  feature(d) a very lonely repairman who never got a telephone 
  call to come fix one of their washing machines.

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/