IBM OS/360 Mainframe Forth
nick_...@my-deja.com
Does anyone know where I might get hold of a
version of Forth for the IBM Mainframe OS/360?
Thanks
Munir
Sent via Deja.com http://www.deja.com/
Before you buy.
Jay Maynard
<nick_...@my-deja.com> wrote:
>Does anyone know where I might get hold of a
>version of Forth for the IBM Mainframe OS/360?
What platform were you looking to run it on...as an OS started task, or as
an IPLable environment? Batch, 3270 console, 1052/3215, or what? 360, 370
mode (with or without DAT), or ESA/390 mode?
I've bene idly pondering porting an existing Forth to the 370/390, but
haven't had time to pursue it. As it turns out, there's an emulator for that
architecture called Hercules (http://www.snipix.freeserve.co.uk/hercules.htm)
that would serve as a suitable development environmet. Hercules runs under
Linux, and emulates the CPU, as well as disk and tape drives, card readers,
card punches, printers, and line-mode (1052 and 3215) and channel-attached
non-SNA 3270 CRTs. It's far enough along that it'll run OS/360 and OS/390;
the 370 virtual memory OSes (MVS/370, VM/370, and DOS/VSE) probabl;y won't
run just yet, but they could be made to run pretty quickly if only the
Hercules group could get their hands on clean distributions of them.
nick_...@my-deja.com
Mainframe game and will use hercules-370 as a vehicle to learn.
As Forth has its' own environment which I understand, I thought that I
might use Forth on OS/360 in order that I can accomplish something
using a tool I am familiar with.
Till now I am trying to get FSE (Full Screen Editor) from
www.cbttape.org to assemble and link (remember I am a beginner).
If a Forth was availabe on OS/360 that had a full screen editor and
even block file access I might be more productive, than learning
370/Assembler, SVC's, driving 3270 screens.
If one does exist I will also study it to learn how it was implemented.
If one does not exist I may implement one. It will give me something to
get my teeth into.
I was kind of hoping that I would use it under TSO using 3270, but it
would also allow applications developed to run interactive under TSO,
and execute in batch.
At the moment my MVT has no ISPF, no panels that I can call from
clists, and no full screen editor.
If I had Forth/360 I might be able to achieve the same effect.
My PII 350Mhz at home gives me 1.3 MIPS running MVT,
my PI 200Mhz at work gives me 0.15 MIPS.
I thought Forth was originally developed by Chuck Moore on IBM
hardware. Should we start with that, or what else would you suggest?
---------------------------------------------------------------------
In article <slrn8ge9e7....@thebrain.conmicro.cx>,
Stephen Pelc
>Does anyone know where I might get hold of a
>version of Forth for the IBM Mainframe OS/360?
exist at least. I suggest you get an IBMer to help you.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)2380 631441, fax: +44 (0)2380 339691
web: http://www.mpeltd.demon.co.uk - free ProForth downloads!
Jay Maynard
<nick_...@my-deja.com> wrote:
>If a Forth was availabe on OS/360 that had a full screen editor and
>even block file access I might be more productive, than learning
>370/Assembler, SVC's, driving 3270 screens.
Yes, though at some point you'll need to get involved in the rest of the
OS...
>I was kind of hoping that I would use it under TSO using 3270, but it
>would also allow applications developed to run interactive under TSO,
>and execute in batch.
Hm. I'm not sure I'd use the TSO environment to run it under; that saves you
some work on the terminal end, but not much else. In particular, you'll
need to do disk I/O for screen storage.
>At the moment my MVT has no ISPF, no panels that I can call from
>clists, and no full screen editor.
The full-screen editor may be doable, though you won't get ISPF on MVT (it
depends heavily on MVS-provided facilities). There's also the minor detail
that ISPF is a licensed program product, and so isn't available for fre,
unlike MVT.
A Forth full-screen editor for the 3270 should actually be pretty simple to
implement once you get the basic 3270 handling done; since the 3270 is a
block-mode device and all editing is done locally, the Forth screen editor
would simply have to handle seeing which lines changed and replacing them in
the memory image of the screen and handle a few PF keys for things like
saving and navigation from one screen to the next.
>My PII 350Mhz at home gives me 1.3 MIPS running MVT,
>my PI 200Mhz at work gives me 0.15 MIPS.
That's pretty typical, though there are some significant performance
enhancements in the works.
>I thought Forth was originally developed by Chuck Moore on IBM
>hardware. Should we start with that, or what else would you suggest?
I remember reading about that; if it's freely available, it'd make a great
starting point. Otherwise, we'd have to start with writing enough of a
kernel (inner interpreter, some basic words, some amount of I/O) to be able
to get things to load from DASD.
m_l...@my-deja.com
but I cannot read it. I do not know if the tape still may be read at all.
Russian Beta-Forth used to have an OS/360 version, I don't know
how they did console i/o.
Where did you get that IBM/360 from?
How much RAM it has, how fasty it is, and what is it for?
IIRC MVT has no built-in dialogue system, we used to run
special dialogue programs.
Maybe, you want to communicate via the system console?
In this case, you could take a Forth written in C and port
it by replacing the i/o routines.
plaw...@arcbs.redcross.org.au
"m_l...@my-deja.com" <m_l...@my-deja.com> wrote:
.
.
.
> Maybe, you want to communicate via the system console?
> In this case, you could take a Forth written in C and port
> it by replacing the i/o routines.
Right there is part of the problem. First you have to get the C,
and second you have to code the I/O. I wasn't able to do either
easily, in my application.
I came up against these issues quite a few years ago now, when
I was obliged to do some heavy sophisticated stuff without tools -
so I rolled my own to get a Forth style VM (not a full blown Forth).
In particular, I didn't have a C (or I would have used that!), or
full access to underlying I/O (I had to mix and match with Cobol
source generated by a special tool, and had to remain consistent
with its choices). If you're constrained at all the same way,
you might do what roughly what I did:-
- make heavy use of macros in an assembler;
- make sure you get diagnostics related to your design working,
as part of the conditional assembly via the macros;
- DON'T do I/O, just implement the whole thing as a coroutine
which you can call as a subroutine from a wrapper in Cobol or
whatever you have, and make I/O become service requests to the
wrapper (I had the first call from the wrapper initialise everything,
then patch out the initialise process - a standard convention in
IBM assembler, but not too structured);
- use direct threading (by the time I realised it was more
appropriate I was well on with indirect threading).
Also, you can start with eforth or hforth or some such - I had to
start with hints from Loeliger. That might even make it realistic
if you hand code somehow, without even an assembler, but I really
needed those diagnostics. And watch out for ASCII/EBCDIC issues. PML.
nick_...@my-deja.com
> - make heavy use of macros in an assembler;
>
> - make sure you get diagnostics related to your design working,
> as part of the conditional assembly via the macros;
>
> - DON'T do I/O, just implement the whole thing as a coroutine
> which you can call as a subroutine from a wrapper in Cobol or
> whatever you have, and make I/O become service requests to the
> wrapper (I had the first call from the wrapper initialise everything,
> then patch out the initialise process - a standard convention in
> IBM assembler, but not too structured);
>
> - use direct threading (by the time I realised it was more
> appropriate I was well on with indirect threading).
>
> Also, you can start with eforth or hforth or some such
Thanks very much for the advice. I'll see if I can get hold of the
Russian Forth first.
nick_...@my-deja.com
>
> Yes, though at some point you'll need to get involved in the rest of
the
> OS...
I certainly will.
>
> A Forth full-screen editor for the 3270 should actually be pretty
simple to
> implement once you get the basic 3270 handling done;
Yes Forth's original block style editing fits nicely with the block
mode 3270, and the fact that most text files are FB80.
I've seen the macros for disk i/o GET, PUT etc. that look fairly
straight forward. I haven't seen anything like a seek call though.
Do you have any samples of simple 3270 terminal i/o? Maybe I could
reserve one of the 3270 terminals other than the console for Forth
work, much like the StarTrek game.
It would also seem fairly easy to provide some XEDIT type line prefix
commands to the editor and let it edit all FB80 files.
Jerry Avins
I have to second that. Years ago, I was asked to provide a controller
for an IBM assembly robot. When the leader of the group that needed the
controller (a neighbor of mine) learned that I intended to write in
Forth, he canceled the request and bought IBM's "robot control language"
(at a cost of more than my annual salary), which he touted as "far
superior". Over the next few months, he asked for, and got, several
extensions to the language that added to its power and flexibility. He
made a lot of noise about how much better off he was than he would have
been with a Forth implementation from me. When his project was not yet
complete, he got notice that RCL was considered obsolete, and that
although support would continue, no further extensions would become
available. In desperation, he shelled out for the source code; there was
too much invested by then to start over. The source was Forth, and we
wrote the rest of the extensions in house. (In the unlikely event that
he reads this and recognizes himself, he now learns that I was offered
his job, but refused it.)
The upshot is that I know that IBM has used Forth for at least one
commercial application. You may be in luck.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jay Maynard
<nick_...@my-deja.com> wrote:
>I've seen the macros for disk i/o GET, PUT etc. that look fairly
>straight forward. I haven't seen anything like a seek call though.
There isn't one, really. The sequential access methods are intended to be
exactly that. What you wind up doing is using the direct access method to
work with the samefile and do blocking/unblocking yourself. The other
possibility is simply to suck the whole file into memory and work on it
there. A couple of hundred screens of Forth would only soak up a few hundred
K, especially if you stick to the classic 16x64 screen size.
>Do you have any samples of simple 3270 terminal i/o? Maybe I could
>reserve one of the 3270 terminals other than the console for Forth
>work, much like the StarTrek game.
I don't, but that Star Trek game would be a good place to look...
>It would also seem fairly easy to provide some XEDIT type line prefix
>commands to the editor and let it edit all FB80 files.
Yeah, that's not too hard.
Jack J. Woehr
>
> Hi,
>
> Does anyone know where I might get hold of a
> version of Forth for the IBM Mainframe OS/360?
There are a few of these around, hiding in collections
inside IBM. Never saw a very good one yet.
There used to be polyForth/370, too, I think.
I keep thinking of writing a new one, since I have VM/ESA
access. This should be written in HLASM under CMS. It would
be rather easy.
But there are a lot of other projects first!
--
Jack J. Woehr # Ceterum censeo
PO Box 51, Golden, CO 80402 # in herbas belli
http://www.well.com/~jax/rcfb # ab idem desistamus.
Elizabeth D. Rather
news:390DEA30...@yabbadab.edu...
> nick_...@my-deja.com wrote:
>
> >
> > Hi,
> >
> > Does anyone know where I might get hold of a
> > version of Forth for the IBM Mainframe OS/360?
>
> There are a few of these around, hiding in collections
> inside IBM. Never saw a very good one yet.
>
> There used to be polyForth/370, too, I think.
No, alas, we never released one. Chuck had a Forth for the 370 in about
1971-2 (at NRAO), but as a company we never had any demand for it. That
system was used at the Charlottesville headquarters for data analysis. An
on-line version was in use in Tucson for telescope control, data
acquisition, and graphical analysis. If you asked anyone in Charlottesville
about Forth, the answer was always, "Oh, yes, it's great for
number-crunching, but you could never do anything real-time with it." If you
asked anyone in Tucson, or any of our many guest observers, the answer was,
"Oh, yes, it's great for real-time control and stuff, but you could never do
any number-crunching with it."
Cheers,
Elizabeth
============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
Forth-based products and Services since 1973.
==============================================
Bernd Paysan
> If you asked anyone in Charlottesville
> about Forth, the answer was always, "Oh, yes, it's great for
> number-crunching, but you could never do anything real-time with it." If you
> asked anyone in Tucson, or any of our many guest observers, the answer was,
> "Oh, yes, it's great for real-time control and stuff, but you could never do
> any number-crunching with it."
I've heard that often enough, too. Many people use Forth in embedded
control, and most of them say that it is wonderful for EC, but no good
for anything else. I use Forth for GUIs, visualization, for hardware
simulation, for some number crunching, text conversion, etc., and I've
never used Forth seriously for EC (though a customer of mine does use my
Forth for EC), but I won't say it is no good at it ;-).
Forth is a language to customize. That's why your customized Forth looks
made specially for your purpose. It's not the Forth, it's the extensions
that are specially made for your purpose. And they are written in Forth.
Unfortunately, most people take Forth+extensions just as is and don't
think further.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
gary_b...@my-deja.com
Just out of curiosity, what made you decide that direct threading was the way
to go?
In article <8ebb1e$urb$1...@nnrp1.deja.com>,
plaw...@arcbs.redcross.org.au wrote:
> ...you might do what roughly what I did:-
>
> - make heavy use of macros in an assembler;
>
> - make sure you get diagnostics related to your design working,
> as part of the conditional assembly via the macros;
>
> - DON'T do I/O, just implement the whole thing as a coroutine
> which you can call as a subroutine from a wrapper in Cobol or
> whatever you have, and make I/O become service requests to the
> wrapper (I had the first call from the wrapper initialise everything,
> then patch out the initialise process - a standard convention in
> IBM assembler, but not too structured);
>
> - use direct threading (by the time I realised it was more
> appropriate I was well on with indirect threading).
>
> ...
gary_b...@my-deja.com
Jay Maynard
<gary_b...@my-deja.com> wrote:
>I did a fig-FORTH 370 many years ago [...]
I can't speak to direct vs. indirect threading, never having implemented a
Forth,...but what environment did you do it for, and how'd you approach I/O,
and do you still have a copy hanging around we could build on?
gary_b...@my-deja.com
written to run under VSE (or DOS/VS, as it was called then).
But I still have the assembler source if you have a way to
deal with that.
I made two versions: one a "batch mode" program that used
a card reader/line printer interface, and one to run under
CICS with a 3270 terminal interface. Both versions use a VSAM
DA (direct access) file for the virtual disk, and a (now very
non-standard) VSAM KSDS file interface for data files. I'm sure
this was once was a regular (non-VSAM) direct access interface,
but I may no longer have source for that. I do remember it was
much easier than the VSAM one, and the VSAM one isn't all that
bad.
Reasons why this isn't what you want:
1) not ANS Forth (nor even close)
2) uses EBCDIC for all character data (good in my situation)
3) uses 24-bit addressing (I just HAD to use that high-order
byte of my link field for the length field, and now I
regret it!)
But if you're really desperate, I'm willing to share what I
have.
In article <slrn8h15ms....@thebrain.conmicro.cx>,
jmay...@texas.net wrote:
> ...but what environment did you do it for, and how'd you
approach I/O,
> and do you still have a copy hanging around we could build on?
>
plaw...@arcbs.redcross.org.au
gary_b...@my-deja.com wrote:
> I did a fig-FORTH 370 many years ago, and I ended up using indirect
threading.
> Just out of curiosity, what made you decide that direct threading was
the way
> to go?
Saving a register, simplifying the macros I used to lead into
each word (they had to carry conditional assembly of diagnostics too),
and as a straight performance issue, it would have simplified the
inner interpreter too (enabling me to inline it in many places
rather than have a single copy).
Many of these things were only that awkward because I had to keep
reassigning registers for addressing, since the application ended
up huge even with Forth - it would be just as fair to blame the
need on the 360 range architecture.
Plus, I've been influenced by benchmark stuff collected by people
on this newsgroup. Was it Bernd Paysan? PML.
Jay Maynard
<gary_b...@my-deja.com> wrote:
>My object code probably wouldn't do you any good, as it was
>written to run under VSE (or DOS/VS, as it was called then).
>But I still have the assembler source if you have a way to
>deal with that.
I do, indeed...
>2) uses EBCDIC for all character data (good in my situation)
In an IBM environment, I would expect that EBCDIC is the right answer. Is
there much Forth code out there that assumes ASCII, and would break in an
EBCDIC environment? Does ANS Forth require ASCII?
>3) uses 24-bit addressing (I just HAD to use that high-order
> byte of my link field for the length field, and now I
> regret it!)
You and a LOT of other folks... :-)
>But if you're really desperate, I'm willing to share what I
>have.
Please. If nothing else, it's a starting point, and a place to see what not
to do.
Bernd Paysan
> >2) uses EBCDIC for all character data (good in my situation)
>
> In an IBM environment, I would expect that EBCDIC is the right answer. Is
> there much Forth code out there that assumes ASCII, and would break in an
> EBCDIC environment? Does ANS Forth require ASCII?
Yes, ANS Forth requires ASCII. I don't know how many Forth programs
depend on ASCII.
: star 42 emit ;
certainly does (directly from Starting Forth), but
: star [char] * emit ;
of course doesn't. I'm not sure, but IIRC from the year I worked with an
IBM-compatible mainframe at the university, EBCDIC doesn't support all
ASCII characters. This may not be a problem for Forth itself (if the few
unsupported characters are not used in standard names - or you might
have to use some glyphs like (( for [), but it might be a problem for
porting programs.
gary_b...@my-deja.com
EBCDIC can't support all ASCII characters, but more that there is no One
True Translation Table. EBCDIC has both lower and upper-case brackets
(and braces) defined in at least some places, but all software doesn't
necessarily follow those rules. I ended up using braces ({}) for
brackets ([]), which obviously causes transportability problems with ANS
programs that really want to use braces.
As I told Jay, character/number conversions and certain character
comparisons (i.e. [char] A [char] 0 < ) also cause problems.
But it has remained a darned useful tool for twenty years!
- gary
In article <39128784...@mikron.de>,
Bernd Paysan <bpa...@mikron.de> wrote:
> ... I'm not sure, but IIRC from the year I worked with
an
> IBM-compatible mainframe at the university, EBCDIC doesn't support all
> ASCII characters. This may not be a problem for Forth itself (if the
few
> unsupported characters are not used in standard names - or you might
> have to use some glyphs like (( for [), but it might be a problem for
> porting programs.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> http://www.jwdt.com/~paysan/
>
m_l...@my-deja.com
>
> Jay Maynard wrote:
> > >2) uses EBCDIC for all character data (good in my situation)
> >
> > In an IBM environment, I would expect that EBCDIC is the right answer. Is
> > there much Forth code out there that assumes ASCII, and would break in an
> > EBCDIC environment? Does ANS Forth require ASCII?
>
> Yes, ANS Forth requires ASCII. I don't know how many Forth programs
> depend on ASCII.
>
> : star 42 emit ;
>
> certainly does (directly from Starting Forth), but
>
> : star [char] * emit ;
>
> of course doesn't.
In general, despite the fact that ASCII is a part of ANS Forth,
representing character literals by numbers is a bad style.
No one recoding program will convert number literals representing
chars, while [CHAR] x or 'x' would cause no problem.
The same applies to non-English letters and special signs like (c).
Never use number representations for them, because there is no common one!
> I'm not sure, but IIRC from the year I worked with an
> IBM-compatible mainframe at the university, EBCDIC doesn't support all
> ASCII characters. This may not be a problem for Forth itself (if the few
> unsupported characters are not used in standard names - or you might
> have to use some glyphs like (( for [), but it might be a problem for
> porting programs.
Our IBM-compatible had { } \ , but the character \ was unprintable.
We used -- as the comment sign (BTW, this is how the word \ was translated
to Russian v standarte Fort-83).
The symbols { and } were not at the keyboard, they required an XEDIT macro.
And the printer had no small letters.
There were no symbols ~` , and instead of $ there was the 'goat' symbol.
m_l...@my-deja.com
> On Wed, 03 May 2000 23:03:24 GMT, gary_b...@my-deja.com
> <gary_b...@my-deja.com> wrote:
> >3) uses 24-bit addressing (I just HAD to use that high-order
> > byte of my link field for the length field, and now I
> > regret it!)
>
> You and a LOT of other folks... :-)
I used that byte in the link field for the immediate and smudge
flags. One day I found that when I re-load a file, a word that
should be immediate becomes non-immediate. But when I re-load it
again, everything is ok. And at the next re-load it again aborts.
(Now stop the reading; can you guess what the bug was?)
--------------------------
--------------------------
--------------------------
The bug was the following:
--------------------------
FORGET stored the link field of the word being FORGoTten
into the vocabulary's pointer to the first word.
But the highest byte of the link field contained
the name flags, which therefore went to the vocabulary's
first word pointer!
When the file was re-loaded, the word was created
again and the first-word pointer (that is, the old link field)
went to the new link field. The word was immediate from the moment
of creation. But IMMEDIATE XORed the immediate flag, thus
making the word non-immediate. Nice, isn't it?
m_l...@my-deja.com
>
> - use direct threading (by the time I realised it was more
> appropriate I was well on with indirect threading).
Could you, please, tell us how can one use direct threading
on IBM/370 with its 0..4095 displacements?
Well, if you sacrifice one more register, you get 8K of code space.
It's enough for primitives, and high-level words will start with
B DOCOLON
But:
how would you call them?
BAL R10,DOCALL
DC =A(THEWORD)
?
* RSP - reg for SP
* RRP - reg for RP
* R11, R12 -- base registers
DOCALL AR RRP,NEGATIV4
LA R9,4(,R10)
ST R9,0(,RRP)
BR R10
?
Did you mean something like this or something diifferent?
NEXT
m_l...@my-deja.com
code for IBM, not direct threaded code!):
Let R10 be as sort of "outdated IP".
R10 contains the return address after the last BAL instruction.
One more register always contains -4096. With it, we can
branch forward and backward in the range -4096..+4095 bytes from
the last BAL instruction.
I'll give an example assuming that the stack top is kept in a
register (which is always recommended).
I did not try my code because I do not have an IBM mainframe.
R0 EQU 0
...
R15 EQU 15
BASE1 EQU R11
BASE2 EQU R12
USING FIRSTDEF,R11,R12
* use r11 as base reg for things in the addr range FIRSTDEF..FIRSTDEF+4K,
* use r12 as base reg for things in the addr range FIRSTDEF+4K..FIRSTDEF+8K.
LOCBASE EQU R10
* R2 -- stack top
TOS EQU R2
SP EQU R9
RP EQU R8
NEG4 EQU R7 must always contain -4
NEG4K EQU R6 must always contain -4096
MROT CODE '-ROT'
LR R4,R2 r4:=r2
LM R2,R3,0(SP) load multiple, r2..r3, from 0+(SP)
STM R3,R4,0(SP) store multiple, r3..r4, to 0+(SP)
BR R10
ENDCODE
FARCALL CODE 'farcall'
* Use:
* BAL R10,FARCALL Branch to FARCALL And Link via R10
* DC A(wordToCall) Define Constant, Address_of(wordToCall)
L R3,0(,R10) R3 (any temporary) := Address_of(wordToCall)
SR R10,NEG4 R10 := R10 + 4, bypass the 32-bit address
BR R3
ENDCODE
.... 8K of code ...
**** Forth code:
**** CODE -ROT ... END-CODE \ in the core, call uses base reg = R11 or R12
**** ....
**** : XYZ ... ; \ far call will be needed
**** ... 4096 ALLOT ...
**** : FOO ... ;
**** : BAR ... DUP -ROT + FOO ... ;
XYZ COLON
...
SEMICOLON
.... 8K of something ....
FOO CODE
* DOCALL action -- COLON inserts it automatically
ALR RP,NEG4 room at return stack, logical add is faster
ST R10,0(,RP) save return addr
...
* EXIT action
L R10,0(,RP)
SR RP,NEG4
BR R10
ENDCODE
BAR COLON
...
* DUP
ALR SP,NEG4 add logical reg-reg (logical is faster)
ST TOS,0(,SP)
* -ROT
BAL R10,MROT "call" -ROT, return address goes to R10
LASTR10 EQU * upon return from -ROT, this addr is in R10
* +
AL TOS,0(,SP)
SR SP,NEG4
* FOO
BAL R10,FOO+4096-LASTR10(NEG4K,R10)
LASTR10 EQU * upon return from FOO, this addr is in R10
* XYZ
BAL R10,FARCALL
DC A(XYZ) Define Constant, Address_of(XYZ)
...
SEMICOLON
> plaw...@arcbs.redcross.org.au wrote:
> >
> > - use direct threading (by the time I realised it was more
> > appropriate I was well on with indirect threading).
Well, but what I described is subroutine threading with in-lining.
In a direct threaded system a colon definition should start with
BAL R9, DOCALL
and everything else will be mostly the same.
I'd reserve R10 for the address of NEXT (as I did in my ITC Forth).
Regards, Michael.
Peter Lawrence
>
> plaw...@arcbs.redcross.org.au wrote:
> >
> > - use direct threading (by the time I realised it was more
> > appropriate I was well on with indirect threading).
>
> on IBM/370 with its 0..4095 displacements?
I should perhaps have said, use direct threading if you can. The issues you
mention are part of why my in-advance choice was indirect threading. I
believe (but have not checked) that if you manage your allocation to put all
the primitives in one place, so memory management gets easier, you can get
away with it - because the other memory accesses can work according to
conventions of your own choosing.
But it's been a while, and this part was only theoretical for me anyway, so
don't count on it. PML.
--
GST+NPT=JOBS
I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.
See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.
Anton Ertl
Peter Lawrence <pet...@netlink.com.au> writes:
>m_l...@my-deja.com wrote:
>> Could you, please, tell us how can one use direct threading
>> on IBM/370 with its 0..4095 displacements?
>
>I should perhaps have said, use direct threading if you can. The issues you
>mention are part of why my in-advance choice was indirect threading. I
>believe (but have not checked) that if you manage your allocation to put all
>the primitives in one place, so memory management gets easier, you can get
>away with it - because the other memory accesses can work according to
>conventions of your own choosing.
I don't know the 360/370 enough, but this sounds like the problems we
have with some of the current architectures. E.g., Alpha only has an
indirect jump through a register (no offset): jmp. It has an
instruction for adding a register and a signed 16-bit offset (lda).
Each instruction takes 32 bits, a cell is 64 bits (on Digital Unix and
Linux), and the code field takes two cells in Gforth.
So what we do is we have a pointer to docol in one register ($9) all
the time. All the other run-times (dovar, docon, dodoes etc.) are
close to docol. So the code field of say, a variable, contains in the
first cell
lda $10,dovar-docol($9)
jmp $10
For a word using dodoes, the second cell contains the address of the
code after DOES>.
Primitives are jumped to directly and don't make a problem.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Jay Maynard
wrote:
>So what we do is we have a pointer to docol in one register ($9) all
>the time. All the other run-times (dovar, docon, dodoes etc.) are
>close to docol. So the code field of say, a variable, contains in the
>first cell
>lda $10,dovar-docol($9)
>jmp $10
This translates pretty directly to the 370:
In initialization:
LA R9,DOCOL POINT TO RUNTIMES
USING DOCOL,R9 TELL THE ASSEMBLER WE DID THAT
At the beginning of the runtime routines:
DOCOL DS 0H MARK THE DOCOL ROUTINE
[...]
B NEXT
DOVAR DS 0H MUST COME RIGHT AFTER DOCOL
[...]
B NEXT
[..]
Then the first cell becomes a simple
B DOCOL
or
B DOVAR
since the assembler does the low-level magic needed to keep this straight.
If the run-time routines overflow the 4K addressable from a single base
register, then the initialization fragment becomes
LA R9,DOCOL POINT TO START OF RUNTIMES
LA R10,2048(R9) HALFWAY TO NEXT CHUNK
LA R10,2048(R9) POINT TO NEXT CHUNK
USING DOCOL,R9,R10 TELL THE ASSEMBLER
and the assembler uses R9 or R10 as necessary. The 370 has 16 registers, 15
of which can be used as base registers, so this technique runs dry if you
have lots of fixed code, but Forth generally doesn't have that problem.
Jack J. Woehr
> >lda $10,dovar-docol($9)
> >jmp $10
>
> This translates pretty directly to the 370:
>
> In initialization:
>
> LA R9,DOCOL POINT TO RUNTIMES
> USING DOCOL,R9 TELL THE ASSEMBLER WE DID THAT
>
> At the beginning of the runtime routines:
>
> DOCOL DS 0H MARK THE DOCOL ROUTINE
> [...]
> B NEXT
BTW, GForth probably runs on Linux/390.
m_l...@my-deja.com
Jay Maynard wrote:
> LA R9,DOCOL POINT TO START OF RUNTIMES
> LA R10,2048(R9) HALFWAY TO NEXT CHUNK
> LA R10,2048(R9) POINT TO NEXT CHUNK
It must be
LA R10,2048(,R10)
> USING DOCOL,R9,R10 TELL THE ASSEMBLER
>
> and the assembler uses R9 or R10 as necessary. The 370 has 16 registers, 15
> of which can be used as base registers, so this technique runs dry if you
> have lots of fixed code, but Forth generally doesn't have that problem.
And one more detail,
LA R10,2048(,R10)
vs.
LA R10,2048(R10)
If you look into execution times, you will most probably find out
that address calculations *with* index register are slower than
*without* index register.
The memory operand format is disp(index,base).
Therefore, 2048(10) is
disp=2048, index=R10, no base
while 2048(,10) is
disp=2048, no index, base=R10
If you look into IBM's code, you'll see a lot of disp(,base)'s.
Another trick is using logical addition:
it's normal addition but with strange cc.
If you don't need cc, just use logical addition.
(When I learned it, I did not want to replace A to AL everywhere
manually and left it as is. Now i would replace A to AL in + ,
in SPUSH and maybe some other most frequent units.)
I almost everywhere used:
* if I remember correctly
MACRO
&LAB SPUSH &R,&SP
&LAB ALR &SP,NEG4
ST &R,0(,&SP)
MEND
and an analogous thing for SPOP.
I also had a macro called REFS that could be used as
* : ?2DUP ( 0 0 -- 0 0 ) ( a b -- a b a b )
* OVER OVER OR IF OVER OVER THEN
P2DUP COLON '?2DUP'
REFS OVER,OVER,OR
IF
REFS OVER,OVER
THEN
SEMICOLON
To define REFS (compile references for an arbitrary number of arguments)
read the manual about &SYSLIST
To define macros for IF ELSE THEN etc., read about GBLA GBLB GBLC LCLA LCLB LCLC
SETA SETB SETC &SYSNDX AIF AGO.
MACRO
NEW
LCLA &K
LCLC &L(4)
.REP ANOP
&K SETA &K+1
&L(&K) SETC '&SYSLIST(&K)'(2,1)
AIF (&K LE 4).REP
DC C'&L(1).&L(2).&L(3).&L(4)'
MEND
"the macro builds a constant consisting from 2nd characters of
first four operands of the macro, using the indexed variable &L ".
(Brich & others, "Programmirovanie na yazyke assemblera ES EVM").
I remember I had a stack in Assembler like in Forth.
( >MARK >RESOLVE <MARK <RESOLVE )
(sort of, GBLC &STACK(100) )
It it even possible to have an equivalent of ?PAIRS.
I also found a way to use macro names in-line, that is, the above code
could be
P2DUP COLON '?2DUP'
XREFS OVER,OVER,OR,IF,OVER,OVER,THEN,SEMICOLON
(for IMMEDIATE words you call macros)
but at that time the system already worked, I had more interesting things to
do and I did not want to rework it this way.
(I was a student at the University then)
Anton Ertl
And possibly on the POSIX layer of OS/390 (at least that shouldn't
need much tweaking). However, only indirect threaded, because nobody
has written direct threading support yet.
Jack J. Woehr
> In article <39164033...@ibm.net>,
> "Jack J. Woehr" <jwo...@ibm.net> writes:
> >BTW, GForth probably runs on Linux/390.
>
> And possibly on the POSIX layer of OS/390 (at least that shouldn't
> need much tweaking). However, only indirect threaded, because nobody
> has written direct threading support yet.
My point being is that just compiling it under Linux would give some insights into
porting it to VM or MVS native.
I'm asking around IBMLink if anyone has seen any old Forths for the 370 lying
around.
nick_...@my-deja.com
in any shape or form?
In article <390B2741...@ieee.org>,
Jerry Avins <j...@ieee.org> wrote:
> Stephen Pelc wrote:
> >
> > nick_...@my-deja.com wrote in message <8e6vu2
$4mu$1...@nnrp1.deja.com>...
> > >Does anyone know where I might get hold of a
> > >version of Forth for the IBM Mainframe OS/360?
nick_...@my-deja.com
interfaces will be easier for me to understand. I am not familiar with
CICS & VSAM. So reading cards and printing on SYSOUT will be easier.
-----------------------
In article <8eqb7j$5bu$1...@nnrp1.deja.com>,
gary_b...@my-deja.com wrote:
> My object code probably wouldn't do you any good, as it was
> written to run under VSE (or DOS/VS, as it was called then).
> But I still have the assembler source if you have a way to
> deal with that.
>
> I made two versions: one a "batch mode" program that used
> a card reader/line printer interface, and one to run under
> CICS with a 3270 terminal interface. Both versions use a VSAM
> DA (direct access) file for the virtual disk, and a (now very
> non-standard) VSAM KSDS file interface for data files. I'm sure
> this was once was a regular (non-VSAM) direct access interface,
> but I may no longer have source for that. I do remember it was
> much easier than the VSAM one, and the VSAM one isn't all that
> bad.
>
> Reasons why this isn't what you want:
>
> 1) not ANS Forth (nor even close)
> 2) uses EBCDIC for all character data (good in my situation)
> 3) uses 24-bit addressing (I just HAD to use that high-order
> byte of my link field for the length field, and now I
> regret it!)
>
> But if you're really desperate, I'm willing to share what I
> have.
>
> In article <slrn8h15ms....@thebrain.conmicro.cx>,
> jmay...@texas.net wrote:
> > ...but what environment did you do it for, and how'd you
> approach I/O,
> > and do you still have a copy hanging around we could build on?
> >
>
nick_...@my-deja.com
that a JMP $abcd1234 was a universal type of instruction (ignoring word
size). A processor without a direct jmp is a big surprise to me.
Could you give me an idea why this is so. Is this processor optimized
for indexed addressing?
-----------------------------
In article <8f4eno$907$1...@news.tuwien.ac.at>,
an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> In article <391625...@netlink.com.au>,
> Peter Lawrence <pet...@netlink.com.au> writes:
> >m_l...@my-deja.com wrote:
> >> Could you, please, tell us how can one use direct threading
> >> on IBM/370 with its 0..4095 displacements?
> >
> >I should perhaps have said, use direct threading if you can. The
issues you
> >mention are part of why my in-advance choice was indirect threading.
I
> >believe (but have not checked) that if you manage your allocation to
put all
> >the primitives in one place, so memory management gets easier, you
can get
> >away with it - because the other memory accesses can work according
to
> >conventions of your own choosing.
>
> I don't know the 360/370 enough, but this sounds like the problems we
> have with some of the current architectures. E.g., Alpha only has an
> indirect jump through a register (no offset): jmp. It has an
> instruction for adding a register and a signed 16-bit offset (lda).
> Each instruction takes 32 bits, a cell is 64 bits (on Digital Unix and
> Linux), and the code field takes two cells in Gforth.
>
> So what we do is we have a pointer to docol in one register ($9) all
> the time. All the other run-times (dovar, docon, dodoes etc.) are
> close to docol. So the code field of say, a variable, contains in the
> first cell
>
> lda $10,dovar-docol($9)
> jmp $10
>
> For a word using dodoes, the second cell contains the address of the
> code after DOES>.
>
> Primitives are jumped to directly and don't make a problem.
>
> - anton
> --
> M. Anton Ertl Some things have to be seen to be
believed
> an...@mips.complang.tuwien.ac.at Most things have to be believed to
be seen
> http://www.complang.tuwien.ac.at/anton/home.html
>
mlg
wrote:
> I thought that a JMP $abcd1234 was a universal type of
> instruction (ignoring word >size). A processor without
> a direct jmp is a big surprise to me.
But
A R1,=F'5'
is also not an add-with-immediate instruction!
It's equivalent to
A R1,LIT5
..
LIT5 DC F'5'
>
> Could you give me an idea why this is so. Is this processor
> optimized for indexed addressing?
At first, it's not a processor optimized to something.
It's a General-Purpose Computer!
I think, it's done to
1) facilitate creation of relocatable code
2) complicate creation of non-relocatable code
3) keep instruction size smaller
4) keep instruction set smaller
5) to keep the processor smaller
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!