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

Drew Derbyshire wrote:

On 4/14/20 11:32 PM, Peter Coghlan wrote:

I wonder could this have been the COBOL compiler abusing MVCL instructions
in situations where they were not the appropriate instructions to use?

Perhaps instructions such as MVCL would be expected to be "hot spots" because
they can deliver a relatively large amount of work for a single instruction?
Or is it that implementations of this instruction were sometimes poorer than
they ought to be and they were really not delivering bang for buck?

I was told back in the 1980s that for performance reasons MUSIC moved
4096 bytes of data via a series of MVC commands in place of one MVCL.

My feeling is that something like this would be likely to have remained in
place forever more. I had a look through the "current" MUSIC nucleus object
deck for 256 byte MVC instructions (X'D2FF'). I found this section of code in
the URMON module:

BR R14
LTR R4,R4
BZ 2224(R0,R12)
MVC 3112(4,R0),16(R0)
MVC 4056(4,R0),540(R0)
MVC 4060(4,R0),548(R0)
MVC 1456(256,R4),3072(R0)
MVC 1712(256,R4),3328(R0)
MVC 1968(256,R4),3584(R0)
MVC 2224(256,R4),3840(R0)
MVC 472(1,R4),3524(R12)
BR R14
MVC 3072(256,R0),1456(R13)
MVC 3328(256,R0),1712(R13)
MVC 3584(256,R0),1968(R13)
MVC 3840(256,R0),2224(R13)
MVC 16(4,R0),3112(R0)
MVC 540(4,R0),4056(R0)
MVC 548(4,R0),4060(R0)

Without doing a bit of work to figure out exactly what is going on, it is
not clear to me whether these code sections get called four times in a loop
or not but it could be the case.

Of course, it's harder to locate MVCL instructions (X'0E') in an object deck
but there seem to be a few in there, including this one in URMON:

ST R11,144(R0,R13)
XC 440(32,R13),440(R13)
LA R0,1456(R0,R13)
LA R1,1024(R0,R0)
SLR R3,R3
MVCL R0,R2
MVI 472(R13),32
L R5,3444(R0,R12)
ST R13,620(R0,R0)
LR R8,R12
L R12,3644(R0,R12)
BALR R14,R12

However, this could have been added later the lifetime of MUSIC.

Regards,
Peter Coghlan.

--
Drew Derbyshire

"All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"

On 4/15/20 3:21 PM, adriansutherland67 wrote:

Does your email server implement?SPF, DKIM and DMARC?

Yes, yes, and yes.

Along with other things.



--
Grant. . . .
unix || die

I've never seen a commercial spam filter that was worth a damn,
honestly. But that goes for most commercial software.

The big issue with spam is the combination of sleazy people and
clueless people. Over the past fifteen years or so, spam has started to
look more and more like real email, and real email has started to look
more and more like spam. As someone who has managed large mail
installations in the past, I can say that keeping ahead of it is
essentially impossible, and in a large installation requires quite
literally daily tweaks. On my mail server here with about ~110 users,
the tweaks are about every 3-4 days. It's a pain in the ass.

Oh, and the issues I'm having with gmail aren't for messages sent from
groups.io's mail servers, but from mail.neurotica.com.

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

On 4/15/20 5:21 PM, adriansutherland67 wrote:

Does your email server implement?SPF, DKIM and DMARC?

Yes, no, and yes. I ran DKIM until about two weeks ago, and I'll be
starting it up again soon.

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

开云体育

On Wed, 15 Apr 2020 at 17:47, Joe Monk <joemonk64@...> wrote:

No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction.

Little is that simple these days...

MOVE characters (MVC)
– If <=16 bytes, it is cracked into separate load and store μops
– If > 16 bytes, it is handled by a hardware sequencing logic inside the LSU
– If the destination address is 1 byte higher than the source address
(and they overlap), it is special cased into hardware as a 1-byte
storage padding function (with faster handling)
– If the destination address is 8 byte higher than the source address
(and they overlap), it is special cased into hardware as a 8-byte
storage padding function (with faster handling)
– If other kinds of address overlaps, it will be forced into millicode
to be handled a byte at a time

MOVE LONG

? A special engine is built per CP chip for aligned copying or padding
functions at a page granularity
– The page-aligned copying or padding is done “near memory”, instead
of through caches, if
? Not executed inside a transaction
? Padding character specified is neither X’B1’ nor X’B8’
? A preceding NIAI instruction does not indicate that the storage data
will be used subsequently
? The operands must not have an access exception
? Length >= 4K bytes
? For moves: source and destination addresses are both 4K-byte aligned
? For padding: destination address is 4K-byte aligned
– Otherwise, the move process will operate through the caches (L1, L2…)
– Note that the evaluation is revised every unit-of-op
– For padding, even if starting address is not aligned, millicode pads
in cache to the first 4K-byte boundary, then uses “near
memory” pad engine for the next aligned 4K-byte pages until the
remaining length is less than 4K bytes. After that,
padding is done in cache again
? Near-Memory engine usage is best when the amount of data involved is
large and the target memory is not to be
immediately consumed in subsequent processes
– Since the special engine is shared within a CP chip, contention
among processors is possible
– Such contention is handled transparently by millicode and additional
delay may be observed



Tony H.

Does your email server implement?SPF, DKIM and DMARC?

Mine?

Yes, no and no.

I'm pretty sure I haven't suffered from any instances of spam runs
sent out with my domain name forged as the source address although
I am not sure I can believe that the spammers are smart enough to
have checked for the existance of SPF and decided that this would
make it not a worthwhile thing to do. I really only have it so
that if this did happen, the recipients would have an opportunity
to identify what they are receiving as forged and unauthorised.

Regards,
Peter Coghlan.