On Wed, 2020-04-01 at 23:51 +0200, rvjansen@... wrote:
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
converted to an executable object, including those for s390x - which
works for Linux on Z and OMVS, now called USS.
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 linker. ?On
this I am only familiar with Linux. ?Binutils LD is designed for Linux.
I appreciate your point from an earlier email that all the 64
instructions have their counterparts in the older versions of the
architecture, but without a 24 bit ISA backend for LLVM I think this
is going to be very difficult; modern assembler can be done without
base registers (¡®baseless¡¯) and to package that code into 4K CSECTs
CSECTS do not need to be 4K, but base register limitation is 4K.
or with chained base registers seems complex; cannot do any long
jumps either. Also, that LLVM backend needs to be able to write
standard .TXT objects; this seems less involved.
The interesting thing here is that more languages than C can generate
LLVM; SWIFT comes to mind; there is also an LLVM assembler with which
some people might be at home.
It might be necessary to have a parallel implementation in??s/370
assembler. Do note that we are fairly spoiled on the mainframe with
good assemblers; DSECTs and usable macro processors are not available
for all ISA¡¯s and I am fairly underwhelmed with GNU AS.
As I ultimately became. ?I gave up on GNU AS. ?That is why my Stand-
Alone Tool Kit (SATK) has an assembler that works for all instructions
(that I have implemented, one system behind) and creates output
suitable for IPL'ing a mainframe. ?The toolset was the limitation for
new Hercules development that needed testing. ?The goal of SATK is to
provide the toolset to facilitate new Hercules development.
A full object deck output is a design goal I have been working on
sporadically for quite awhile.
I¡¯ll hope we have some critical mass soon so we can build on that. It
would be good to start out in C as we can leverage code that is
already there.
I hate C. ?Try to stay as far away as I can these days. ?Python is my
language of choice. ?That does not mean I can not work in C. ?I can.
?Hercules is in C.
¸é±ð²Ô¨¦.
?
On 1 Apr 2020, at 23:19, Harold Grovesteen <h.grovsteen@...>
wrote:
On Wed, 2020-04-01 at 10:25 -0700, adriansutherland67 wrote:
After sleeping on it, considering time etc. I think I will
3. What I would find more fun (after all maintaining others code
can
be thankless!), is a CREXX along the lines indicated below in
this
thread, harvesting existing code etc. First job is PoC versions
of
the RAssembler, RBytecode, and RInterpretor. Targets Ubuntu,
Windows,
Mac, and VM/370 (because I want to) from the get go. Other ports
should therefore be straightforward ...
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 there without a compiler to generate the
RAssembler.
Harold Grovesteen
