Re: 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%20Utilities/ - 
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