(By the way, I replied to your recent "Inquiring minds" email but I fear you
may not have seen my reply as Google tends to route anything I send these days
isnto their recipients spam folder or otherwise quarantine it. Apparantly
Google regards me as a notorious source of spam or something for some time now.
I also sent emails to other Google mail users both on the this list not and
these also seem to have disappeared into black holes...)

Oh dear. I have had the problem in the past of my e-mails being
picked up by spam filters and so has my brother. I think in our case
it was a case of the Scunthorpe problem
() - look at my
surname!

On Thu, Apr 16, 2020 at 06:30 PM, Peter Coghlan wrote:

save two bytes:

AH R1,=H'8'

Peter ... You have taught me what F meant!

You are gentlemen ... thank you!

It is for a 24 bit address.

A

Mostly!

LA works as long as the answer fits in 24 bits so it's no good for
adding 8 to a negative value in R1 for example.

An alternative solution is:

A R1,=F'8'

If memory is really tight, you could use this and possibly save two bytes:

AH R1,=H'8'


Regards,
Peter Coghlan.

Is there a better way than this to add 8 to R1?

On Wed, Apr 15, 2020 at 07:07 PM, Harold Grovesteen wrote:

That is how we all learned. ?Getting slapped a few times helps with the
memory. ?There is no way to learn assembler, like any language, without
doing it.

Slowly learning - I think I can do USING and DROP and use MACROs as well ... includes/copybooks

A

On Wed, Apr 15, 2020 at 01:00 PM, Harold Grovesteen wrote:

I remind everyone working with GCC on VM/370 that it is a port of the
old i370 architecture version of GCC. ?The modern optimizations are
likely to be quite limited. ?This GCC is not the same version of GCC
that is used today.

Exactly - however we don't really care about the backend optimisations (after all we use Hercules which has completely different timing characteristics), but we do the front end / C ones; for example dead code removal, unwinding loops, register assignments, avoiding recalculating constants, inlining etc.?

On Thu, Apr 16, 2020 at 03:14 PM, Dave Wade wrote:

one disk had “crap” when I think it was part of the GCCCMS library.

I recovered it ... the real issue is that it was work in progress

A

On Thu, Apr 16, 2020 at 05:35 PM, Dave Wade wrote:

split the pre-processor into a separate phase.

Perhaps ... and 16mb is not very very tiny ... I think it is the optimisers that will cause dramas!

On Thu, Apr 16, 2020 at 03:22 PM, Harold Grovesteen wrote:

?I have a concern
that the efforts here will actually cause GCC to fork. ?That there will
end up being a GCC for VM and one for MVS and DOS. ?While GCC itself is
relatively static, it does incur some change.

How is GCC supported? ?Is there a team or just some adhoc approach?

I believe that it it did "self host" at least once. And why would we not try again? Pragmatically however there?is no particular problem with cross compiling it (and I am guessing this might be faster!).?

And compiling it against GCCLIB would be a benefit for us CMS users.

At the moment Paul is "GCC" for CMS?and MVS ...?

The big problems are
- Having the optimiser work in low memory environments. Basically the whole program needs to be in memory for the optimisers to optimise
- Forward port the mainframe character encoding
- Forward port the S/370 backend
- Both these refect that fact that we are using a very old version of GCC

开云体育

On Thu, 2020-04-16 at 07:46 -0700, adriansutherland67 wrote:

On Thu, Apr 16, 2020 at 02:38 PM, Harold Grovesteen wrote:
dependent upon Paul for a rebuild
of GCC??
I think not ... the source is all published.?

One thing I want to do is a build of GCC using the GCCLIB library

A
?

Source availability was never the issue. ?The ability for GCC to
actually build itself on the various target platforms have been the
issue.

There have been a lot of angst about 31-bit addressing in MVS 3.8J.
?This was implemented in a forked version of Hercules. ?It was driven
by the fact that GCC could not compile itself in a 24-bit world of an
MVS address space. Thank you Paul.

My question was about constraints within CMS that might preclude self
compilation by GCC. ?The actual answer appears to be that we do not
know.

Could GCC be compiled outside of CMS? ?Absolutely. ?I believe this is
how we managed to actually port it. ?But that was not my earlier
question.

Perhaps, Adrian, you will answer these questions. ?I have a concern
that the efforts here will actually cause GCC to fork. ?That there will
end up being a GCC for VM and one for MVS and DOS. ?While GCC itself is
relatively static, it does incur some change.

How is GCC supported? ?Is there a team or just some adhoc approach?

Harold Grovesteen

开云体育

On Wed, 2020-04-15 at 18:15 -0500, Joe Monk wrote:

Question:
–?What should be used to move or clear large blocks of data?
§?础苍蝉飞别谤:
§?There are several ways to move or clear a large block of storage
provided in the z/Architecture
One MVCL instruction
Loops of MVCs to move data
Loops of MVC <Len>,<Addr>+1,<Addr> or XC <Len>,<Addr>,<Addr> to
pad/clear an area
§?As discussed on page 31 titled “MOVE LONG
颈苍蝉迟谤耻肠迟颈辞苍蝉”,?–?惭痴颁尝颈蝉颈尘辫濒别尘别苍迟别诲迟丑谤辞耻驳丑尘颈濒濒颈肠辞诲别谤辞耻迟颈苍别蝉
–?惭颈濒濒颈肠辞诲别颈蝉补蹿颈谤尘飞补谤别濒补测别谤颈苍迟丑别蹿辞谤尘辞蹿惫别谤迟颈肠补濒尘颈肠谤辞肠辞诲别
??Incurs some overhead in startup, boundary/exception checking, and
ending
–?惭痴颁尝蹿耻苍肠迟颈辞苍颈尘辫濒别尘别苍迟别诲耻蝉颈苍驳濒辞辞辫蝉辞蹿惭痴颁蝉辞谤齿颁蝉
–?惭颈濒濒颈肠辞诲别丑补蝉补肠肠别蝉蝉迟辞蝉辫别肠颈补濒苍别补谤-尘别尘辞谤测别苍驳颈苍别蝉迟丑补迟肠补苍诲辞辫补驳别-
alignedmoveandpage-alignedpadding
Can be faster than dragging cache lines through the cache hierarchy
However, the destination data will NOT be in the local cache
§?As such, the answer is “it depends” as there is no one answer to
all situations. There are many factors to
肠辞苍蝉颈诲别谤?–?奥颈濒濒迟丑别迟补谤驳别迟产别苍别别诲别诲颈苍濒辞肠补濒肠补肠丑别蝉辞辞苍?
??Then moving/padding “locally” will be better by using MVCs or
齿颁蝉?–?滨蝉迟丑别蝉辞耻谤肠别颈苍濒辞肠补濒肠补肠丑别?
??Then moving/padding “locally” may be better by using MVCs, or
齿颁蝉?–?贬辞飞尘耻肠丑诲补迟补颈蝉产别颈苍驳辫谤辞肠别蝉蝉别诲?
??The more data you are required to process, the more you may benefit
from using MVCL due to special hardware engines used by millicode
–?贰虫辫别谤颈尘别苍迟补迟颈辞苍颈蝉,迟丑别谤别蹿辞谤别,丑颈驳丑濒测补诲惫颈蝉别诲

This is all very interesting, but has no relevance to Hercules.
?Hercules has no concept of millicode or cache lines.

All instructions are implemented in the "hardware" of Hercules, namely,
its C program, and all memory is directly accessed.

Now, a discussion about how Hercules is designed and its impact on the
underlying real hardware is an entirely different matter. ?We know that
the instruction execution can itself be significantly improved. ?A
proprietary emulator that executes on the same type of hardware as does
Hercules is reported to be significantly faster than Hercules. ?Most of
us lack access to such an emulator. ?

However, this proprietary emulator does not, as far as I know, execute
S/370 architecture. ?So is irrelevant in a topic of VM/370. ?Hercules
is the only relevant emulator here and you all saw my general
recommendation for Hercules performance.

Harold Grovesteen

On Thu, Apr 16, 2020 at 02:38 PM, Harold Grovesteen wrote:

dependent upon Paul for a rebuild
of GCC??

I think not ... the source is all published.?

One thing I want to do is a build of GCC using the GCCLIB library

A

On Wed, 2020-04-15 at 20:51 +0100, Dave Wade wrote:

BTW, can CMS compile GCC on VM/370???There were issues with that on
MVS.

Originally it could on VM/370, but not on SP or later because you
lose memory. I don't know how Paul builds it these days, he may use
the 380 mods..?
There were some modules that needed different optimization, but I
can't remember which ones they were.
Because CMS is so small you get more usable memory than on MVS.

Dave

?

So are all of the operating systems dependent upon Paul for a rebuild
of GCC??

In this context I am assuming he is delivering object modules to the
other platforms with linking occurring on the target platform.

Harold