[fpc-devel] Re: On a port of Free Pascal to the IBM 370
I guess I should make a few qualifiers here.
I think that a mainframe port should be made, if for no other reason than to
keep C from being the only choice for developing programs on mainframes (other
than Cobol, of course, and dinosaurs like me that know it are rapidly becoming
petroleum!)
I know the 370. I know more-or-less how file I/O is done under OS/VS1 which
MUSIC/SP provides an emulation mode for. I don't (yet) know the machine code
for the 390 processor and I do not know the interface for which services from
Linux/390 are implemented, I mean, is it a set of different supervisor calls
(the way OS/VS1 is) or is it a single supervisor call with lots of parameters
(the way MS-DOS with (mostly) INT 21 and Windows 98/Me/XP and Linux on Intel
are)?
Certainly I'll eventually learn them. But for right now, for me to know it
works right, I have to implement it for what I know works. Then I can go on to
improve what it does or expand the port to the more powerful mainframe. As I
said - or if I didn't say it, it needs saying - I have to crawl before I can
walk or run.
There's another thing. In at least a few parts of the compiler there are uses
of naked, manifest constants which is always a bad idea. I think someone once
said that the only manifest constants that should be used in a program are 0
and 1 and maybe not even them.
Changing from manifest constants to CONST definitions does two things, it
ensures consistency, and, if your language has cross-reference capability, the
cross-reference utility can tell you every place you've used an identifier; It
can't tell you where you've used a constant.
I remember this from back when I first learned Assembly Language, probably
around 1976-77, one of the things instructor Don Lacy taught us is to define
registers by creating a set of names on the order of
R0 EQU 0
R1 EQU 1
thru
R15 EQU 15
So when you use
PROGRAM START
BALR R12,R0
USING *,R12
The assembler will list the usage of R12 and R0 here in the cross-reference.
It would not list anything if you'd just used 0 and 12.
As anyone who read this can remember a few messages ago when one guy read my
error when I wanted to show how the $DEFINE parser only supports {$DEFINE and
that (*$DEFINE doesn't work, but thought I didn't know you can't close {* with
*) and thought when I did it wrong as {* instead of (* and thought I meant the
{ when I meant ( just goes to show how easy it is to confuse { and (.
It's easy to confuse 0 (zero) and O (capital o) 1 and I (upper case i), 1 and l
(lower case L), and sometimes 8 and 0. Not using them as constants but as
constant identifiers means it's easier to spot and to be consistent.
There's also on piece of code - it's probably in SCANNER.PAS - where there's a
construct of something like
if CH in ['A'..'Z']
which won't work on some processors; EBCDIC doesn't define A-Z (or a-z) as a
continuous set; there are non-alphabetic characters between I and J (and
between i and J) and another intervening point. This goes back to the days
when code was entered on 029 keypunches. (And yes, I remember those days, and
NOT fondly!)
So I guess the question is, for submitting proposed changes, do I ask someone -
and if so whom - for SVN access and a branch to use to put corrections in, or
do I pick a specific person - and again, if so, whom - or place (and where) to
submit source code changes to provide some fixes as I make them? Not
necessarily just for this, I noticed some things I think should be cleaned up.
Just under the presumption of always following rule #1: DON'T BREAK THE BUILD.
If it worked (built without an error) when you put your dirty hands on it, it
had damn well better still work when you've pulled your greasy, sticky fingers
away!
The Lessons of history teach us - if they teach us anything - that no one
learns the lessons that history teaches us.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
--- Begin Message ---
From: Paul Robinson
Sven Barth writes (edited for brevity):
> It's not that I'm scared that you want to tackle this it's more that I've
> seen that you based your How-To on assumptions
> that are wrong or at least "not good" and wanted to help you in this regard.
That was part of the reason I started looking at this first, before "formally"
making an announcement. I wanted to see what kind of mess I was getting myself
into. This is not a trivial task and it's something I've wanted to do for
several years. I want to do this right, and it will take time. To quote from
some movie I can't remember, "If it takes six months, it takes six months. If
it takes a year - or a year and a half - it takes that long."
> Well, then let's get started with bringing you on track:
> 1. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's
> better to work with the most recent source.
I didn't know the sources were up to 2.7 already. I installed Tortoise SVN - I
was using Mercurial because that's what a different project is using, and I'm
an agnostic, so I'll use anyone's source code repository. I'm writing a
(fiction) book about life after death and I was using CVS for its releases I
think. So anyway, I used Tortoise SVN and retrieved the Compiler directory,
and (I just looked) PP doesn't mention what version it is, VERSION does, and it
says 2.6.0. I do want to keep a 2.6.0 branch to keep sources for the existing
compiler, I will find where the bleeding edge branch is and create a 2.7.1
version there.
>2. I suggest you to use the Lazarus IDE to do compiler development
Once I found you can build console-mode apps using it I switched back to it.
Interesting with all the crapola to implement windows support, even console,
e.g. DOS WINDOW - applications are looking more and more like full Windows
ones. I've discovered that Lazarus has raised my standards in IDEs from the
dead (pun intentional!) It is an order of magnitude much easier to work with
than the Turbo Vision clone version. Since I found interest in including
cross-reference in the compiler to be less than lukewarm I decided to write an
external cross-reference program. One quick question which the manual doesn't
seem to answer, is whitespace allowed between { and $ in the case of {$INCLUDE
'X'}? I sometimes see it in some of the compiler sources and I'm not sure if
that's allowed or it is effectively 'diking out' the $ command. The manual
does not say one way or the other.
> 3. add unit "i_i370" to the "compiler" unit and directory "systems"..
> "compiler" unit .. OS .. not architecture. add a "i_osvs1" to
> that unit... first need the architecture support... corresponding CPU unit
> ... "cputarg" in the unit "compiler". ...suggest you copy
> the directory of an architecture... name that "i370"
As I've said, I'll take all the help I can get. Anything to make the work
easier is appreciated.
> 4. stumpled upon "sysutils" don't need to care ... yet. These are only
> needed if you compile programs for the target platform ...
> might want to stub "System" ... most important part .. real entry point
> "begin...end." in "program" NOT the real entry point,
> this part is called "PASCALMAIN" and is called from within the real entry
> point
This makes sense, when you run a compiled program usually you do not want to
start the program first, you want to start the run-time-library and have it,
after it's been initialized, to start the program.
That (PASCALMAIN) will have to change, the object file format for 370 machines
limits a CSECT to 8 characters, with the optional characters @ # and $. So I
might call it MAIN or possibly #MAIN. (On the PDP/11, most operating systems
(RT-11, RSTS/E, RSX) defined the main program in any language as ".MAIN." )
> So at the beginning you can mostly concentrate on your "i370" directory with
> adding some types here and there (like the assemblertype that you already
> added).
> might be best to first target Linux ... split into "architecture support" "OS
> support"
I may-probably will - put it in at the same time but in stub form for the
reasons I stated above; I don't know Linux/370 and might not know why, if a
program doesn't work, why it doesn't. The first step is to at least generate
"Hello World" and have it actually execute on the target. Possibly insert
"readln" so I know it correctly reads and writes I/O. Then going on from
there. Plus - this is sort of a cheat - I have compiler sources that can tell
me how to implement some of the run-time library. Then I can go on and add
what Linux requires for this implementation vs. what it does on (I almost said
Windows!) I386 hardware or whatever has to be done.
Paul
The Lessons of history teach us - if they teach us anything - that no one
learns the lessons that history teaches us.
--- END MESSAGE---
___
fpc-deve
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
WITH message^Paul.Robinson DO BEGIN Mark Morgan LLoyd wrote: > I've got reservations because of the EBCDIC issue. That's not a problem. You write a program on the 370, the machine does the internal conversion. Most people never notice the difference. The standard characters are the same in all versions of EBCDIC, the conversions for A-Z, a-z, 0-9, space and most symbols @!#$&*()-+ etc. are pretty much cut and dried. I actually wrote an ASCII <- ->EBCDIC conversion to be able to view some text files from a mainframe PDS (their version of unix's tarball files) in order to understand what is going on. > I'm sure Paul has his reasons that we all need to respect, but I don't think > that using > a 370 emulator (i.e. at least two architectures out of date) plus an obsolete > operating > system is the place to start. Again, I have to target what I know. A program written for the 370 will run on a 390. Having gotten the simpler version up and running, I can put other things in place and potentially add hooks later. If I have to learn the extensions for the 390 and how Linux/370 works, well, I guess I can probably add another 2 years on top of the conversion. I'd like potentially to see something running by Summer 2012, just in case Michel Nostradamus and the Aztecs were interpreted correctly and there'll be no tomorrow on December 22! (I'm going to be real upset if that happens, I just bought a five-year extension on my Magic Jack phone service before the price goes up.) > I admit to having considered this as a long-term project, but > what I don't have is a good understanding of the architecture's > assembler-level programming. I've been updating the Wikibook (another one of Wikipedia's projects) on IBM 370-series assembler, just to remind myself of what was involved and to keep my skills sharp. Having gotten back into this I'm starting to remember things I'd forgotten. > However I think I need to make the general point here that > "IBM Assembler" is understood in the industry to encompass > that which is needed to write application-level programs in > CISC assembler plus macro support etc.), and that even > somebody skilled in that particular black art might need to > enter unfamiliar territory when it comes to the operations > required by a compiler's code generation (e.g. commercial > programming doesn't do large amounts of stack-relative addressing). They didn't tell us that at the time, but a lot of people did and didn't realize it. By convention, Register 13 is used by a called program as a save area to store the user's registers. If you're a subroutine (or if you prefer, you wrote a subroutine or wrote your program so that it would operate as one) the caller hands you R13 with an address of a 72-byte save area to store a spare word (used by Fortran and PL/I), plus all of the registers in the order 13-15 and 0-12 so you can return them as they were given to you and you don't have to worry about how you use them. So what some people did was use the register version of the OS/VS1 GETMAIN macro, which tells the operating system to return a block of storage space in register 1. Then they'd save the current value of register 13 at address 4 in this block, then put the block's address in R13. Just like doing a linked list. Now you have a place for any routines you might call to store your registers, plus, if you store your variables as offsets in register 13, you've created a stack to put your variables on and your program, since it uses no local writable memory, is fully reentrant and position independent. So you got it, you got a stack, reentrancy and PIC all for free and most of us who wrote code doing it that way never even knew it. Tomas Hajny wrote: > Still, starting with the Linux for S/390 (or are S/390 and S/370 completely > different animals?) Similar to the differences between Pentium and IAS-64, the 390 is a 64-bit version of the 370. > probably a very good idea to avoid having to tackle both a different HW > platform and > a different OS at the same time (the Linux port to S/390 apparently uses > ASCII > according to what I found on Internet). Obviously, the OS may follow once the > new HW platform is in working state. I may take a look at it, but I figured getting a Linux port was a substantial amount of work I didn't want to do right now; I have code I can use for the OS target I am using, I can know if it works or know why it doesn't. Not so for the 390 or for Linux. I can, conceivably include it as an option with it stubbed for the moment, then as I figure out how to implement the interface to it I can. Michael Schnell wrote: > As for using Linux: I have no idea how this works in practice, so I can't > comment on that. Which more-or-less makes two of us. > I know that people here use Hercules inside linux to > develop for zSeries, but then again running a linux > inside that seems a bit like
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
Paul Robinson wrote the following on 19/01/12 23:28:01: > I guess I should make a few qualifiers here. > > I think that a mainframe port should be made, if for no other reason than to > keep C from being the only choice for developing programs on mainframes > (other than Cobol, of course, and dinosaurs like me that know it are rapidly > becoming petroleum!) I used IBM's VS/Pascal and Pascal/VS for many years and really liked them. (IUO and public versions of the same compiler.) And there's always PL/1! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: On a port of Free Pascal to the IBM 370
Start of Message by Paul Robinson
WITH MESSAGE DO
BEGIN
Sven Barth wrote (quoting me):
>> That (PASCALMAIN) will have to change, the object file format for 370
>> machines limits a CSECT to 8 characters, with the
>> optional characters @ # and $. So I might call it MAIN or possibly #MAIN.
>> (On the PDP/11, most operating systems (RT-11,
>> RSTS/E, RSX) defined the main program in any language as ".MAIN." )
>
> If I understand you correctly, then you might confuse label names with
> section names.
No, I know exactly what I mean. Label and section names are under the same
rules in an assembler program on the 370, and a CSECT in 370 Assembly language
THENAME CSECT
is equivalent to
Procedure THENAME;
(* in Pascal *)
SUBROUTINE THENAME
C in Fortran
10 PROCEDURE DIVISION.
20 PROGRAM-ID. THENAME.
30* In Cobol
int thename(void) {
/* In C */
}Excepting, of course, for the brain-dead moronic behavior of assigning
case-sensitivity to identifiers in C.
Paul
The Lessons of history teach us - if they teach us anything - that no one
learns the lessons that history teaches us.
END.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
Paul Robinson wrote:
> I guess I should make a few qualifiers here.
>
> I think that a mainframe port should be made, if for no other reason
> than to keep C from being the only choice for developing programs on
> mainframes (other than Cobol, of course, and dinosaurs like me that
> know it are rapidly becoming petroleum!)
Or Java. And while it's conceivable that Oracle could make themselves
sufficiently unpopular that the rest of the World junked Java, as I
understand it IBM has so much invested in e.g. hardware assist engines
that they'd be the last to jump ship.
> I know the 370. I know more-or-less how file I/O is done under OS/VS1
> which MUSIC/SP provides an emulation mode for. I don't (yet) know the
> machine code for the 390 processor
My understanding is that the 390 is backwards-compatible with the 370
and 360. However you don't need to understand the binary code, since FPC
emits assembler source which is processed by the standard GNU assembler
as a backend. There are FPC command-line options that allow you to save
this with varying levels of explanatory comments for later inspection,
although some of the more juicy stuff requires that FPC be recompiled
with EXTDEBUG=1 on the make command line.
> and I do not know the interface for which services from Linux/390 are
> implemented, I mean, is it a set of different supervisor calls (the
> way OS/VS1 is) or is it a single supervisor call with lots of
> parameters (the way MS-DOS with (mostly) INT 21 and Windows 98/Me/XP
> and Linux on Intel are)?
I'll see what I can dig out. However I think that
http://linuxvm.org/present/SHARE102/S9236uw.pdf is a good starting
point, and most if not all other Linux ports work on the basis of a
single supervisor call with multiple parameters (nota bene: the
constants identifying syscalls vary across architectures).
> Certainly I'll eventually learn them. But for right now, for me to
> know it works right, I have to implement it for what I know works.
> Then I can go on to improve what it does or expand the port to the
> more powerful mainframe. As I said - or if I didn't say it, it needs
> saying - I have to crawl before I can walk or run.
I want to be quite unambiguous about this: from the point of view of
implementing a compiler, it is not that the 390 is more powerful but
that the 370 is broken. Referring to
ftp://sourceware.org/pub/gcc/summit/2003/Porting%20GCC%20to%20the%20IBM%20S390.pdf
section 3.1, it was at least partially fixed in the 390 circa 1992, and
if I recall correctly GCC doesn't support older systems. Now you're the
guy with the relevant industry experience: are there still pre-'92
mainframes in commercial or academic service? My understanding is that
"big iron" of that vintage has been recycled for its precious metal, and
that contemporaneous "micro mainframes" are woefully underpowered by
today's standards- and I write as somebody who's got some fairly old
kit, and who prefers not waiting 24 hours for a trial compilation to
throw bugs.
> There's another thing. In at least a few parts of the compiler there
> are uses of naked, manifest constants which is always a bad idea. I
> think someone once said that the only manifest constants that should
> be used in a program are 0 and 1 and maybe not even them.
Yes, but I'd suggest making sure that your architecture-specific code is
clean before moving on to the generic stuff.
[Snip]
> I remember this from back when I first learned Assembly Language,
> probably around 1976-77, one of the things instructor Don Lacy taught
> us is to define registers by creating a set of names on the order of
>
> R0 EQU 0
> R1 EQU 1
> thru
> R15 EQU 15
>
> So when you use
>
> PROGRAM START
>BALR R12,R0
>USING *,R12
>
> The assembler will list the usage of R12 and R0 here in the
> cross-reference. It would not list anything if you'd just used 0 and
> 12.
OK. Important point here: FPC uses gas (GNU Assembler) or equivalent as
a backend, and so has to generate assembler that it's happy with. I came
across exactly the same issue a few months ago with MIPS: it turns out
that symbolic register names were only added to gas comparatively
recently so if FPC wants to generate code that will assemble reliably it
can't use them... at least for a few more years.
> As anyone who read this can remember a few messages ago when one guy
> read my error when I wanted to show how the $DEFINE parser only
> supports {$DEFINE and that (*$DEFINE doesn't work, but thought I
> didn't know you can't close {* with *) and thought when I did it wrong
> as {* instead of (* and thought I meant the { when I meant ( just goes
> to show how easy it is to confuse { and (.
"The senator's still wrong." :-)
If you really want to be strict, I'd suggest that it would be reasonable
to be able to close { with *) or (* with }, since (* and *) are digraphs
for { an
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
Mr Paul Robinson wrote: >> Still, starting with the Linux for S/390 (or are S/390 and S/370 >> completely different animals?) > > Similar to the differences between Pentium and IAS-64, the 390 is a > 64-bit version of the 370. I think you mean x86-64 there, but if you really do mean the IA-64, then that's... not entirely correct. The IA-64, AKA Itanium or in some quarters Itanic, is profoundly different from the Pentium at all levels. As I understand it the 390 and later the zSeries are evolutionary steps from the 370 and earlier 360. The correct analogy there is that x86-64 (x64) is an evolutionary step from the Pentium, and from the earlier '486 and '386. More to the point, post-'92 390s are an evolutionary step from the 370, plus they have facilities for inline literals that older machines lack. Insisting on using /only/ 370 facilities when there are one or two things in 390s that make life much easier is comparable to insisting on writing a compiler for the original 8086 when the '186 and all successor chips had the pusha/popa opcodes that made life much easier. >> probably a very good idea to avoid having to tackle both a different >> HW platform and a different OS at the same time (the Linux port to >> S/390 apparently uses ASCII according to what I found on Internet). >> Obviously, the OS may follow once the new HW platform is in working >> state. > > I may take a look at it, but I figured getting a Linux port was a > substantial amount of work I didn't want to do right now; I have code > I can use for the OS target I am using, I can know if it works or know > why it doesn't. Not so for the 390 or for Linux. I can, conceivably > include it as an option with it stubbed for the moment, then as I > figure out how to implement the interface to it I can. Start off with Linux, using the existing RTL as a starting point. There isn't that much in it that's written in assembler, and trying to redo swathes of it based on your existing code is going to make life difficult for everybody- both future maintainers and people who are trying to help you in the initial port. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
Am 20.01.2012 01:21, schrieb Mr Paul Robinson:
1. Also there were quite a few changes from 2.6.0 to 2.7.1 and thus it's
better to work with the most recent source.
I didn't know the sources were up to 2.7 already. I installed Tortoise SVN - I
was using Mercurial because that's what a different project is using, and I'm
an agnostic, so I'll use anyone's source code repository. I'm writing a
(fiction) book about life after death and I was using CVS for its releases I
think. So anyway, I used Tortoise SVN and retrieved the Compiler directory,
and (I just looked) PP doesn't mention what version it is, VERSION does, and it
says 2.6.0. I do want to keep a 2.6.0 branch to keep sources for the existing
compiler, I will find where the bleeding edge branch is and create a 2.7.1
version there.
Before 2.6.0 was branched from SVN trunk the version was called 2.5.1.
An odd minor number (here the "5") always indicates that it's a
development version. After 2.6.0 was branched (which was still named
2.5.1 at that time) trunk immediately became 2.7.1 and is available
either through SVN or from the FTP server containing the daily snapshots.
The SVN URL for the 2.7.1 sources (also called development version) is
here: http://svn.freepascal.org/svn/fpc/trunk
Please checkout the complete trunk directory and not only the compiler
one. It might be that you need some of the additional tools and also you
can then test whether your platform can be compiled using the Makefile
as well (though the Makefile needs to be adjusted first for this).
The version information of FPC is located in
$fpcdir/compiler/version.pas and there indeed "2.7.1" is encoded.
2. I suggest you to use the Lazarus IDE to do compiler development
Once I found you can build console-mode apps using it I switched back to it.
Interesting with all the crapola to implement windows support, even console,
e.g. DOS WINDOW - applications are looking more and more like full Windows
ones. I've discovered that Lazarus has raised my standards in IDEs from the
dead (pun intentional!)It is an order of magnitude much easier to work with
than the Turbo Vision clone version. Since I found interest in including
cross-reference in the compiler to be less than lukewarm I decided to write an
external cross-reference program. One quick question which the manual doesn't
seem to answer, is whitespace allowed between { and $ in the case of {$INCLUDE
'X'}? I sometimes see it in some of the compiler sources and I'm not sure if
that's allowed or it is effectively 'diking out' the $ command. The manual
does not say one way or the other.
A compiler directive "{$...}" (or "(*$...*)" ) is only detected as one
if the "$" follows immediatly the opening comment sign. Thus a space
character (or anything else) is often used to disable a directive (it's
just a normal comment then).
4. stumpled upon "sysutils" don't need to care ... yet. These are only needed
if you compile programs for the target platform ...
might want to stub "System" ... most important part .. real entry point "begin...end." in
"program" NOT the real entry point,
this part is called "PASCALMAIN" and is called from within the real entry point
This makes sense, when you run a compiled program usually you do not want to
start the program first, you want to start the run-time-library and have it,
after it's been initialized, to start the program.
That (PASCALMAIN) will have to change, the object file format for 370 machines limits a
CSECT to 8 characters, with the optional characters @ # and $. So I might call it MAIN
or possibly #MAIN. (On the PDP/11, most operating systems (RT-11, RSTS/E, RSX) defined
the main program in any language as ".MAIN." )
If I understand you correctly, then you might confuse label names with
section names.
PASCALMAIN is a placeholder (a label) for the final address where the
code of PASCALMAIN is put to by the linker. You can think of PASCALMAIN
as a procedure. In fact e.g. the Windows RTLs contain the following code:
=== code begin ===
procedure PascalMain; external 'PASCALMAIN';
//in the entrypoint procedure:
...
PascalMain;
...
=== code end ===
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
On Fri, January 20, 2012 01:21, Mr Paul Robinson wrote: . . > much easier to work with than the Turbo Vision clone version. Since I > found interest in including cross-reference in the compiler to be less > than lukewarm I decided to write an external cross-reference program. One . . You may want to look at pasdoc (http://pasdoc.sourceforge.net) - I believe that it provides (among other things) also the cross-reference generation functionality. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
Paul Robinson wrote: >>> That (PASCALMAIN) will have to change, the object file format for >>> 370 machines limits a CSECT to 8 characters, with the optional >>> characters @ # and $. So I might call it MAIN or possibly #MAIN. >>> (On the PDP/11, most operating systems (RT-11, RSTS/E, RSX) >>> defined the main program in any language as ".MAIN." ) >> >> If I understand you correctly, then you might confuse label names >> with section names. > > No, I know exactly what I mean. Label and section names are under the > same rules in an assembler program on the 370, and a CSECT in 370 > Assembly language I suspect that this will depend on the target operating system, so the Linux ABI may differ from e.g. MUSIC/SP. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
On 21.01.2012 20:12, Paul Robinson wrote:
Start of Message by Paul Robinson
WITH MESSAGE DO
BEGIN
Sven Barth wrote (quoting me):
That (PASCALMAIN) will have to change, the object file format for 370 machines
limits a CSECT to 8 characters, with the
optional characters @ # and $. So I might call it MAIN or possibly #MAIN. (On
the PDP/11, most operating systems (RT-11,
RSTS/E, RSX) defined the main program in any language as ".MAIN." )
If I understand you correctly, then you might confuse label names with section
names.
No, I know exactly what I mean. Label and section names are under the same
rules in an assembler program on the 370, and a CSECT in 370 Assembly language
THENAMECSECT
is equivalent to
Procedure THENAME;
(* in Pascal *)
SUBROUTINE THENAME
C in Fortran
10 PROCEDURE DIVISION.
20 PROGRAM-ID. THENAME.
30* In Cobol
int thename(void) {
/* In C */
}Excepting, of course, for the brain-dead moronic behavior of assigning
case-sensitivity to identifiers in C.
This is something you'll definitely need to investigate, because the
mangled Pascal identifers (for variables, procedures, etc.) are normally
MUCH longer than 8 characters. For procedures they contain the unit
name, the procedure's name and the types of all arguments (for
overloading). You can see this if you compile a program with the "-al"
argument, which will tell the compiler to leave the assembler files so
you can take a look at them (normally called "unitname.s").
Another possibility would be to research whether there are other
assemblers which don't have that restriction. Is there C++ available for
this system? If so you can check what that uses as an assembler, because
C++ uses mangled names as well.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
On 1/21/2012 15:49, Mark Morgan Lloyd wrote: Paul Robinson wrote: >>> That (PASCALMAIN) will have to change, the object file format for >>> 370 machines limits a CSECT to 8 characters, with the optional >>> characters @ # and $. So I might call it MAIN or possibly #MAIN. >>> (On the PDP/11, most operating systems (RT-11, RSTS/E, RSX) >>> defined the main program in any language as ".MAIN." ) >> >> If I understand you correctly, then you might confuse label names >> with section names. > > No, I know exactly what I mean. Label and section names are under the > same rules in an assembler program on the 370, and a CSECT in 370 > Assembly language I suspect that this will depend on the target operating system, so the Linux ABI may differ from e.g. MUSIC/SP. ABI means what? for those of us reading and trying to keep up ;) this might even be something new to those attempting to work on such a port task ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
At 08:12 PM 1/22/2012, waldo kitty wrote: On 1/21/2012 15:49, Mark Morgan Lloyd wrote: Paul Robinson wrote: I suspect that this will depend on the target operating system, so the Linux ABI may differ from e.g. MUSIC/SP. ABI means what? for those of us reading and trying to keep up ;) this might even be something new to those attempting to work on such a port task ;) "Application Binary Interface" Ralf ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
waldo kitty wrote: > No, I know exactly what I mean. Label and section names are under the > same rules in an assembler program on the 370, and a CSECT in 370 > Assembly language I suspect that this will depend on the target operating system, so the Linux ABI may differ from e.g. MUSIC/SP. ABI means what? for those of us reading and trying to keep up ;) this might even be something new to those attempting to work on such a port task ;) Application Binary Interface, it's the overall set of register usage conventions, syscall numbers and so on. I'm unsure the origin of the term but over the last ten years or so it's come into common usage for Linux, and extended to other OSes. For Linux on IBM mainframes, see http://linuxvm.org/present/SHARE102/S9236uw.pdf as a starting point. Also I've put info on assembler formats etc. at http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources (I needed comparative info when looking at MIPS a few months ago), I was hoping to add links to ABIs for each architecture but didn't get that far since something else intervened. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: On a port of Free Pascal to the IBM 370
Mark Morgan Lloyd wrote: For Linux on IBM mainframes, see http://linuxvm.org/present/SHARE102/S9236uw.pdf as a starting point. Also I've put info on assembler formats etc. at http://wiki.lazarus.freepascal.org/Assembler_and_ABI_Resources (I needed comparative info when looking at MIPS a few months ago), I was hoping to add links to ABIs for each architecture but didn't get that far since something else intervened. I've added a fragment of assembler code (from the Linux kernel) to the above page as an example. Digging around, it looks as though Linux assumes at least an S/390 G5, according to Wp this model was released in 1998, I don't know whether any are still in service. Noting Paul's intention to target MUSIC/SP, I think that the points that distinguish this are (a) it's compatible with older IBM OSes and (b) in conjunction with a suitable emulator it has TCP/IP. I don't think that postings earlier in this thread make clear that it's (apparently) the only free OS that has this combination of features, and whilst I've still got misgivings over e.g. its use of EBCDIC I can "see where he's coming from". -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
