¿ªÔÆÌåÓý

Re: Dynamic / split stacks (gcclib)
Reading about PL/I in wikipedia, this always cracks me up: Announced with IBM S/370 in 1970, it shipped first for the DOS/360 <https://en.wikipedia.org/wiki/DOS/360> operating system in August 1971,
By [email protected] · #909 ·
Re: Dynamic / split stacks (gcclib)
Just thinking out aloud, can we avoid stack variables, and use the stack only for register save/returns? Then you could have nesting limits, like mainframe Rexx has, according to the stack you set
By [email protected] · #908 ·
Re: Dynamic / split stacks (gcclib)
It being IBM PLI/F it must have seen some serious use in the 1966-1971 era - don¡¯t let the old Hursley geezers hear you ;-) In the 80¡¯s-90¡¯s I only did some voodoo programming with it - the
By [email protected] · #907 ·
Re: Dynamic / split stacks (gcclib)
From what I remember the free PL1 is a mess. It usually works but I don¡¯t think any one has made serious use of it. Pretty sure assembler support routines could be added to retrieve the data from an
By Dave Wade · #906 ·
Re: Dynamic / split stacks (gcclib)
It doesn't rule out calling PL/I *programs* via SVC 202 which, I think, is the way rexx external functions would need to be packaged (in sum, modules). In any case does PL/I on VM/370 support EPLIST
By adriansutherland67 · #905 ·
Re: Dynamic / split stacks (gcclib)
Would that rule out calling Rexx external functions written in PL/I? Ren¨¦.
By [email protected] · #904 ·
Dynamic / split stacks (gcclib)
First progress (remembering I am keen to get gcclib fit for purpose asap so I can play rexx): -? GCCLIB global variables (e.g. stdin) working and being rolled out. - About to move to RESLIB only -
By adriansutherland67 · #903 ·
Re: BREXX/CMS vs BREXX
Right you are.
By Harold Grovesteen · #902 ·
Re: BREXX/CMS vs BREXX
Ah ... We could have REXX on bare big iron :-) We all hate C! Lets keep it very easy C ... Adrian
By adriansutherland67 · #901 ·
Re: BREXX/CMS vs BREXX
Do not know rust. ?So no opinion. Harold
By Harold Grovesteen · #900 ·
Re: BREXX/CMS vs BREXX
ELF is not mainframe object. ?While a lot of the information is similar, the two have major differences. ?Worked with both and know this. ?One of the major limitations of ELF is actually the
By Harold Grovesteen · #899 ·
Re: BREXX/CMS vs BREXX
Hi Harold, as per my other reply, in sum I think that at least initial versions will be C for sure. I hope it will be interesting, and you are welcomed to the team in whatever level you like :-) We
By adriansutherland67 · #898 ·
Re: BREXX/CMS vs BREXX
We love Rust! And also GoLang might be applicable in some areas. Or indeed REXX itself might be the right tool for some aspects ... We need a very modular architecture, and I will do a diagram of what
By adriansutherland67 · #897 ·
Re: BREXX/CMS vs BREXX
btw, do we like Rust https://www.rust-lang.org <https://www.rust-lang.org/> ?
By [email protected] · #896 ·
Re: BREXX/CMS vs BREXX
I also suspect it it going to be C - but its backend will not be the standard assembler generator, but LLVM. The clang compiler can generate LLVM, which can be interpreted by an LLVM interpreter, or
By [email protected] · #895 ·
Re: BREXX/CMS vs BREXX
What is the intended implementation language? ?While it has not been explicitly stated, I am suspecting C. Personally, I would find this area interesting. ?Although it is not clear to me how you get
By Harold Grovesteen · #894 ·
Re: BREXX/CMS vs BREXX
That's easy ... I'll do whatever you say is the right answer :-)
By adriansutherland67 · #893 ·
Re: BREXX/CMS vs BREXX
I considered it ... but it is yesterday's news in 2020 (the year that keeps on giving!)
By adriansutherland67 · #892 ·
Re: BREXX/CMS vs BREXX
But I am happy you did not suggest BREXXIT. What are we going to do with cases like: if datatype("0110 1101",'B¡¯) then say ¡®yes¡¯ which succeeds on ooRexx and BREXX, but fails on CMS as well as
By [email protected] · #891 ·
Re: BREXX/CMS vs BREXX
I am fine with MIT - it has the nicest logo. WTFPL is funny but it sounds like one of those jokes you are going to hate in a number of years from now. Ren¨¦.
By [email protected] · #890 ·