RE: Re: Fullscreen application Specs

Ivan

I said in the beginning - I have no arguments with "C"
I have written a lot of "C" and I know you can do a lot with it.
I disagree with you that "C" is efficient on the MF.
I worked at a shop with 30,000 MIPS.
I was very much involved in performance tuning. C was a killer.
This wasn't; that long ago - maybe 5 years .

You said:

 "believe the idea is definitely the other around : The 
-->"general" logic is coded in C (array management, building 
-->the screen, stuff like that) - and the stuff that is 
-->intrinsic to the system is assembler stuff (that deals w"

IVAN - You are missing the point entirely.

The environment  is a full screen multi tasking environment running under
CMS
Thats the application

The editor/browser is a SUBTASK

The application logic about the editor is the least complicated thing about
this and the idea was to have a base that would allow you to write and
fullscreen transctions within this environment. Sort of a MINI CICS/

The editor was just the first task and is really about 10 percent of the
code.
NO - "C" is not the proper language to do what I am doing in the heavy
routines.
Even on a PC, where I love to work in "C", for this kind of programmng I
would exit to assembler.
 
I investigated the possibility of using "C" for the user interface in the
beginning . Rejected it for several reasons.
Among them effeciency. Of performance and coding and work place
environement, But mostly because most of the proponents of using "C" talked
the talk but couldn’t walk the walk... 
Didn’t get any real offer of help besides RTFM

And I have no idea what you are trying to say about writing my own routines
in assembler for string handling.
Are you serious. That’s the solution. I am not in the mood to invent "C" 
My project was a full screen solution in  vanilla VM/370
 
The difference between us here is that I agree with you in theory. But only
in theory.

The hard facts are that I am almost finished with the application and Paul
and it appears you also are still discussing theory.
Which is fine - But please stop making suggestions about what I should Have
done. 

ITS DONE.
Its moot at this stage -- 

I would Love to add a "C" subroutine somewhere to make you all happy (And me
ALSO) but from what I understand it will be larger than all the rest of the
apllication.  
I  remember a thread of about two weeks ago about needing a special loader
because the object code doesnt fit on  the disk properly

My loop to build a map is around 60 instructions in assembler - Includiing
highlighting and  cursor positining and decision making
I could have written that in "C" in 35. but then I would have to write
another 800 to build the maps and simulate BMS.

I already have canned tools that do that for me in assembler. So it was a no
brainer.

SUGGESTION

Lets forget this discussion - Not worth the effort. And getting us off the
point.

I have a few subroutines that still need to be written - If any one wants to
attempt them in "C".  I will give them full support and assistance and
information etc.etc.etc.

I will also participate for the learning process.

But if its just talk - shoulda coulda woulda - then its a waste of time -
and lets get off the subject.
The application (s) are almost finished and we had this discussion a month
ago.

Roc








-->-----Original Message-----
-->From: [email protected] 
-->[mailto:[email protected]] On Behalf Of Ivan Warren
-->Sent: Thursday, August 05, 2010 01:38 
-->To: [email protected]
-->Subject: Re: [H390-VM] Re: Fullscreen application Specs
-->
-->Rocky wrote:
-->> 
-->>  
-->> Setting bits on and off or using an  Execute instruction 
-->or loading a 
-->> PSW is not going to happen in "C" those are the 
-->instructions that you 
-->> need the assembler for. or you can change the logic..
-->
-->For setting bits, it might just do that - It all depends on 
-->how the C backend is organized... More about stuff like LPSW 
-->and Interruptions handling afterwards... But you'd be 
-->surprised of how efficient the machine code generated by GCC is!
-->
-->>  
-->> Also not sure how effecient it is without the new 
-->instruction sets - 
-->> which we don't have on VM6 - SRPT etc.
-->> A main frame is not a byte oriented machine so are you 
-->going to move 
-->> byte byte until you get a binary 00.
-->> That can't be more effecient than assembler.
-->
-->Ok.. 2 things :
-->
-->Current hercules DOES allow for a S/370 architecture with a 
-->lot of the added niceties that came with S/390 and even 
-->z/Arch. Nothing contrary to the architecture here. The S/370 
-->POP gives the "mandatory" instructions and some optional 
-->ones - but doesn't prevent the architecture to be extended 
-->while still remaining within the confines of the architecture. 
-->See "feat370.h" in the source tree.
-->
-->Now, for 'moving byte by byte until you get a binary 0' (that'd be a
-->strcpy() right ?) - first, you can have it coded in 
-->assembler if need be
-->- (if you insist on doing a TRT to find the 0) - but from 
-->what I have seen, the code generated by gcc is usually 
-->pretty hard to beat ! But then again, I'm not even talking 
-->about using the "Standard C library" 
-->here.. You might be willing to use C strings at some point, 
-->but nothing prohibits using those for lightweight stuff only.
-->
-->Basically, I'm really seeing using C here the same way PL/S is used.
-->
-->>  
-->> Just the fact that "C" is almost portable means that a lot of the 
-->> nitty grittty system things can't be done. Or cant be done as 
-->> effeciently as in assembler. How do you do an LPSW 
-->instruction in "C" 
-->> -- Maybe its possible but I wouldn;t have the time to 
-->learn right now,
-->>  
-->> THe tools  you choose should match the application and in 
-->this case I 
-->> wouldn;t know how to start desiging this aplication to work in "C".
-->>  
-->> Certain routines I could have done in "C" but I didn' get 
-->the response 
-->> when I asked How I call "C" from assembler to do a 
-->subroutine, And I 
-->> am inventing enough wheels as it as with this app. I dont 
-->want to get 
-->> into uncharted waters with the "C".
-->>  
-->
-->I believe the idea is definitely the other around : The 
-->"general" logic is coded in C (array management, building 
-->the screen, stuff like that) - and the stuff that is 
-->intrinsic to the system is assembler stuff (that deals with 
-->the LPSW, Interrupts, and generally all the stuff that is 
-->privileged - as well all the stuff that requires to access 
-->the underlying OS (CMS in this case) like DMSFREE/DMSFRET, 
-->FSREAD & FSWRITE, listing files, getting the disk access table, etc..
-->
-->That's pretty much what I did some time ago to have a 
-->'diskmap' module under CMS to generate a Minidisk MAP on 
-->each volume. (see "dmap" in 
-->http://games.groups.yahoo.com/group/H390-VM/files/Other%20Uti
lities/ - unfortunately, I'm not sure were I put the source of that thing !)

*****************

Now.. There's an issue also...

All current efforts around C on S/370 are limited to GCC 3.3.4 - because
support for the old style - S/370 compatible - with OS like linkage
conventions were dropped after GCC 3.3.4.

Current GCC 4 & beyond only use the so called "s390" and "s390x" target
architectures - with ELF linkage (this was necessary because backporting the
old S/370 style backend to the new architecture would have been almost
impossible - barring a complete rewrite).

However, not all hope is lost!

It's possible to

1) Take ELF generated object and generate TEXT files out of them (I know, I
tried, and it works).
2) It would require to write assembly routines using the s390 ELF ABI
linkage (stack structure is different - as well as registers usage) - but
nothing prohibits having an intermediate conversion linkage layer.

--Ivan