RE: Re: Fullscreen application Specs

> or loading a PSW is
> not going to happen in "C" those are the 
> instructions that you need the
> assembler for. 



That too. And how often do you need to do one
of those?


 
In this application quite a bit
 
take a look at the GSVC ASSEMBLE source


  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of
kerravon86
Sent: Friday, August 06, 2010 11:54 
To: [email protected]
Subject: [H390-VM] Re: Fullscreen application Specs


  

--- In [email protected] <mailto:H390-VM%40yahoogroups.com> , "Rocky"
<rocsystems@...> wrote:
>
> Mike & Mike
> 
> Slow down a bit ---
> I'm sure he meant it in the nicest way -----

Absolutely correct.

> I have written a lot of "C" (not on the mainframe) and 
> it was a lot of fun, 

And mainframe C is even more fun, as I suspect
you will find out when you actually try it.

> I said in the previous Memo - My emulator is written 
> in "C" , I wrote a
> large chunk of it
> And I love 8088 assembler - 
> But there are certain things that you can do just as well in in old
> fashioned "C".

Like 90% of an application.

> I am not talking about the newer Object Oriented 
> stuff where everything is
> in black boxes.
> And you are never sure what you are getting

When I write in C, I see the 370 assembler (in
my brain) as I type it in.

> But old fashioned "C" is a one to one language as well. Well almost.

Right.

> This application is really very much involved with the system -
> Intercepting interrupts setting wait states etc, etc - lots 
> of multitasking.
> 
> Being a progammer I know that its all doable in "C". 
> Well almost all. But
> some times "C" is not an improvement on assembler (forgetting 
> about the
> generated Code - which is of course less effecient) for the logic.

Sometimes, as in, rarely.

> Setting bits on and off 

That is perfectly doable in C.

> or using an Execute instruction 

If you want to do that, of course you break out
into assembler.

> or loading a PSW is
> not going to happen in "C" those are the 
> instructions that you need the
> assembler for. 

That too. And how often do you need to do one
of those?

> or you can change the logic..
> 
> Of course you can change the logic to match the tool 
> --- but that is a
> limitation that you don't want in this kind of an application.

If you can, demonstrably, write an operating system
in C, there is a possibility that you are
underestimating C's ability.

> Probably a combination of both "C" and assembler
> would be the proper mix.

That's exactly what I was suggesting.

> But I just don't have the time to debug or learn the mainframe "C"

You don't need to learn mainframe C. As I mentioned
earlier, it's the same as on the PC if you stick
to standard C.

> Also not sure how effecient it is without the new 
> instruction sets - which
> we don't have on VM6 - SRPT etc.

Take a look at the generated code, with optimization
on, and try to fault it. Assuming you are writing
standard application code anyway.

> 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.

Use memcpy() instead of strcpy() and watch as it
generates a single MVC instruction. Or if appropriate,
it may do a L or LM instead. Something that would
look too messy in assembler, so it's a case where
C generates faster code than I would personally
write.

> Just the fact that "C" is almost portable means that 
> a lot of the nitty
> grittty system things can't be done. 

Such as? Chaining through system control blocks? Easy.

> Or cant be done as effeciently as in
> assembler. 

Your editor's performance bottleneck is where currently?

> How do you do an LPSW instruction in "C" -- Maybe its possible
> but I wouldn;t have the time to learn right now,

You can't do it in standard C. You can do it via
an extension, but I personally prefer writing
stuff like that in assembler rather than using
the extensions. You can see that for yourself
with PDOS/3x0 if you want.

> 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".

That's why I suggested where to start. I wrote
a message outlining where to plug it in to see
for yourself.

> 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,

Pardon? This looks like a response to me:

http://games.groups.yahoo.com/group/H390-VM/message/7375

> And I am inventing enough wheels as it as with this 
> app. I dont want to get
> into uncharted waters with the "C".

It's not unchartered. I know the way intimately,
and was more than happy to guide you to at least
know what was possible, even if you subsequently
decided that it wasn't for you, and never used
it at all. I wouldn't have been annoyed in the
slightest for having wasted my time on something
that was rejected after explained.

I am annoyed at being told I was non-responsive
though, given that I think that is grossly
innaccurate to say the least.

BFN. Paul.