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
- And what about the C++ front ends ...
But I think that we should aim to keep the MVS and CMS GCC code base together ... there aren't enough users to support 2 versions!
|
Joe, I wonder if we could split the pre-processor into a separate phase. Pretty sure GCC used to build like that on my Atari ST with 4Mb of memory Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 16 April 2020 17:45
To: [email protected]
Subject: Re: [h390-vm] memset help? "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." It was driven by Paul's desire for a single load module, which MVS3.8J could not handle. Had Paul adopted relevant techniques of the time, such as dynamic calls instead a static call to a library, and using work files within the compiler, this would not have been an issue. ? On Thu, Apr 16, 2020 at 10:22 AM Harold Grovesteen <h.grovsteen@...> wrote: 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
|
"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."
It was driven by Paul's desire for a single load module, which MVS3.8J could not handle. Had Paul adopted relevant techniques of the time, such as dynamic calls instead a static call to a library, and using work files within the compiler, this would not have been an issue.
Joe
On Thu, Apr 16, 2020 at 10:22 AM Harold Grovesteen < h.grovsteen@...> wrote: 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 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
|
Folks, ? Not sure if its what I actually said, but in essence, there should be no problems re-building GCC, its just I havn¡¯t done it for some time. There are issues withy disk usage on the GCCCMS ID. Paul complained one disk had ¡°crap¡± when I think it was part of the GCCCMS library. I removed and I ?think this may be why we have issues with the 1.3 Betas¡ ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 April 2020 15:46
To: [email protected]
Subject: Re: [h390-vm] memset help? 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 18:15 -0500, Joe Monk wrote: Question:
¨C?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
¾±²Ô²õ³Ù°ù³Ü³¦³Ù¾±´Ç²Ô²õ¡±,?¨C?²Ñ³Õ°ä³¢¾±²õ¾±³¾±è±ô±ð³¾±ð²Ô³Ù±ð»å³Ù³ó°ù´Ç³Ü²µ³ó³¾¾±±ô±ô¾±³¦´Ç»å±ð°ù´Ç³Ü³Ù¾±²Ô±ð²õ
¨C?²Ñ¾±±ô±ô¾±³¦´Ç»å±ð¾±²õ²¹´Ú¾±°ù³¾·É²¹°ù±ð±ô²¹²â±ð°ù¾±²Ô³Ù³ó±ð´Ú´Ç°ù³¾´Ç´Ú±¹±ð°ù³Ù¾±³¦²¹±ô³¾¾±³¦°ù´Ç³¦´Ç»å±ð
??Incurs some overhead in startup, boundary/exception checking, and
ending
¨C?²Ñ³Õ°ä³¢´Ú³Ü²Ô³¦³Ù¾±´Ç²Ô¾±³¾±è±ô±ð³¾±ð²Ô³Ù±ð»å³Ü²õ¾±²Ô²µ±ô´Ç´Ç±è²õ´Ç´Ú²Ñ³Õ°ä²õ´Ç°ù³Ý°ä²õ
¨C?²Ñ¾±±ô±ô¾±³¦´Ç»å±ð³ó²¹²õ²¹³¦³¦±ð²õ²õ³Ù´Ç²õ±è±ð³¦¾±²¹±ô²Ô±ð²¹°ù-³¾±ð³¾´Ç°ù²â±ð²Ô²µ¾±²Ô±ð²õ³Ù³ó²¹³Ù³¦²¹²Ô»å´Ç±è²¹²µ±ð-
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
³¦´Ç²Ô²õ¾±»å±ð°ù?¨C?°Â¾±±ô±ô³Ù³ó±ð³Ù²¹°ù²µ±ð³Ù²ú±ð²Ô±ð±ð»å±ð»å¾±²Ô±ô´Ç³¦²¹±ô³¦²¹³¦³ó±ð²õ´Ç´Ç²Ô?
??Then moving/padding ¡°locally¡± will be better by using MVCs or
³Ý°ä²õ?¨C?±õ²õ³Ù³ó±ð²õ´Ç³Ü°ù³¦±ð¾±²Ô±ô´Ç³¦²¹±ô³¦²¹³¦³ó±ð?
??Then moving/padding ¡°locally¡± may be better by using MVCs, or
³Ý°ä²õ?¨C?±á´Ç·É³¾³Ü³¦³ó»å²¹³Ù²¹¾±²õ²ú±ð¾±²Ô²µ±è°ù´Ç³¦±ð²õ²õ±ð»å?
??The more data you are required to process, the more you may benefit
from using MVCL due to special hardware engines used by millicode
¨C?·¡³æ±è±ð°ù¾±³¾±ð²Ô³Ù²¹³Ù¾±´Ç²Ô¾±²õ,³Ù³ó±ð°ù±ð´Ú´Ç°ù±ð,³ó¾±²µ³ó±ô²â²¹»å±¹¾±²õ±ð»å
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
|
Re: REXX Interpreter immediate commands
Pardon if I answer this twice. I had a crash, right when I hit?send a few minutes ago.
I was only describing the HI immediate command implementation in the original REXX.
Almost all the multiuser, multitasking, and asynchronous event processing is handled in the VM Control Program.? This design allows CMS to be treated as a single user system. There? is one application running. It may synchronously?call other programs. It can use simple? Input/Output operations which are treated as synchronous.
Some events, however, are inherently asynchronous. Timer expirations, communications with other virtual machines, special?asynchronous input/output, etc. CMS interruption?handling is documented in the? VM/370 System Programmer's Guide. In general, CMS applications sign up to be notified of asynchronous events by providing the address of an event handler routine. These handlers can mark events complete by? setting indicators which are polled by mainline code. The mainline routine can also relinquish control by? a WAIT state, so that event handlers POST the completion of events and the mainline code resumes execution.?
The APIs for asynchronous operation are only available to assembler level routines in VM/370.? Later VM systems (more recent than 40 years ago) extended these capabilities to enable client/server application development in CMS. Although VM application vendors (for products like The SAS System, and? the VM:Manager Suite of products) built their own multitasking layers for their products, CMS did not? support true Application Multitasking until about 30 years ago.?
Even 45 years ago,?receiving interrupts, and registering event handlers were fundamental?components of? CMS.
Bob Bolch
On Wed, Apr 15, 2020 at 5:24 PM adriansutherland67 < adrian@...> wrote: Bob ... Noted
Am I right in assuming that the concept of processes receiving signals / interrupts, and of registering signal handlers is just alien to VM/370 and can be ignored?
A
|
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.,"
|
Re: OT, mail issues, was Re: [h390-vm] memset help
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
|
Re: OT, mail issues, was Re: [h390-vm] memset help
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
toggle quoted message
Show quoted text
On 4/15/20 5:59 PM, Dave Wade wrote: I don't think I have never seen anything from you marked as "Junk". Some providers don't like groups.io so it might not be you.
I really find most SPAM filters unbelievably bad and I used to manage some very expensive ones.
They allow some utter garbage through whilst often blocking good e-mails.
Why can't they block "PayPal account restricted" messages that have not been anywhere near PayPal.
I can do a much better job than most filters just by looking at from/subject...
I am sure much I get is from having a Taj hotels loyalty card.
As I am sure you know your servers and domains are clean on
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave
McGuire
Sent: 15 April 2020 21:40
To: [email protected]
Subject: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 2:07 PM, Peter Coghlan wrote:
(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 into 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...) I am noticing this to an increasing degree as well. My assumption is that
Google, having spent years pushing "free" email services while making
money on the back end by using the information they mine from it, are now
trying to push yet more people to use gmail accounts.
My mail server predates the very existence of Google as a company by
many years, and has only been use as a spam relay once, a decade ago, for
not quite a day, until I noticed that one of my hundred-or-so users
passwords had been cracked. The only reason I can see for email originating
from my server to be considered spam by Google is that it comes from a non-
gmail server.
This is just my assumption; I have no evidence to suggest that this is why
this is happening, it but it is the only explanation that I've been able to come
up with for this widespread and rapidly growing problem.
This is what happens when people take the lazy or cheap route and get a
"free" email account from a for-profit corporation. Google occasionally does
good things for society, but they are not a charity.
As many have said, and almost nobody actually pays attention to: If you
receive value from a corporation for free, you are the product.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
--
Dave McGuire, AK4HZ
New Kensington, PA
|
Re: OT, mail issues, was Re: [h390-vm] memset help
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
|
Joe:
Please understand that I was one who worked on millicode and hardware on several machines over the years, as well as on emulators. On the machines I worked on, and as long as the data was aligned, MVCL was by far faster for data lengths over 256-bytes. On another machine, I took the lessons from MVCL into the hardware, and speed up MVC substantially. And, granted, there are some machines in which moving a page is best done using 16 MVC instructions, but others in which MVCL outperforms as no interrupt checks need to be made during the move.
It also depends on the implementation of the instruction pipeline, and when a given machine¡¯s internal architecture inserts checks for interrupt status. For example, on one machine I worked on, we found that it was faster to have the MVCL code itself check for the pending interrupt line that was shared with what one would term as the instruction dispatcher. Thus we were able to stay inside MVCL longer, and take fewer breaks. On certain machines, even further optimizations within the pipe architecture can benefit MVCL over MVC, while on other machines, a fixed set of MVCs optimize better.
This is why I stated that the old claim of $MVCL being faster may or may not hold true in the current series of machines. The claim needs to be revalidated, and, if no longer true, a documentation APAR needs to be filed.
Mark ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Joe Monk Sent: Wednesday, April 15, 2020 2:47 PM To: [email protected]Subject: Re: [h390-vm] memset help ? Mark, No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction. ? On Wed, Apr 15, 2020 at 4:28 PM Mark L. Gaubatz via <mgaubatz=[email protected]> wrote: Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ? ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: 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.
>
Drew,
This is very interesting given our recent discussion on the matter.
(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
into 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...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Question:
¨C?What should be used to move or clear large blocks of data? ¡ì?Answer: ¡ì?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 instructions¡±,?¨C?MVCLisimplementedthroughmillicoderoutines
¨C?Millicodeisafirmwarelayerintheformofverticalmicrocode ??Incurs some overhead in startup, boundary/exception checking, and ending
¨C?MVCLfunctionimplementedusingloopsofMVCsorXCs
¨C?Millicodehasaccesstospecialnear-memoryenginesthatcandopage-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 consider?¨C?Willthetargetbeneededinlocalcachesoon?
??Then moving/padding ¡°locally¡± will be better by using MVCs or XCs?¨C?Isthesourceinlocalcache? ??Then moving/padding ¡°locally¡± may be better by using MVCs, or XCs?¨C?Howmuchdataisbeingprocessed? ??The more data you are required to process, the more you may benefit from using MVCL due to special hardware engines used by millicode ¨C?Experimentationis,therefore,highlyadvised
On Wed, Apr 15, 2020 at 6:00 PM Tony Harminc < tharminc@...> wrote: 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)
> ¨C If <=16 bytes, it is cracked into separate load and store ¦Ìops
> ¨C If > 16 bytes, it is handled by a hardware sequencing logic inside the LSU
> ¨C 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)
> ¨C 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)
> ¨C 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
¨C 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
¨C Otherwise, the move process will operate through the caches (L1, L2¡)
¨C Note that the evaluation is revised every unit-of-op
¨C 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
¨C Since the special engine is shared within a CP chip, contention
among processors is possible
¨C Such contention is handled transparently by millicode and additional
delay may be observed
Tony H.
|
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)
¨C If <=16 bytes, it is cracked into separate load and store ¦Ìops
¨C If > 16 bytes, it is handled by a hardware sequencing logic inside the LSU
¨C 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)
¨C 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)
¨C 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 ¨C 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 ¨C Otherwise, the move process will operate through the caches (L1, L2¡) ¨C Note that the evaluation is revised every unit-of-op ¨C 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 ¨C Since the special engine is shared within a CP chip, contention among processors is possible ¨C Such contention is handled transparently by millicode and additional delay may be observed Tony H.
|
Re: OT, mail issues, was Re: [h390-vm] memset help
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.
|
Re: OT, mail issues, was Re: [h390-vm] memset help
Dave,
I don't think I have never seen anything from you marked as "Junk". Some providers don't like groups.io so it might not be you.
I really find most SPAM filters unbelievably bad and I used to manage some very expensive ones.
They allow some utter garbage through whilst often blocking good e-mails.
Why can't they block "PayPal account restricted" messages that have not been anywhere near PayPal.
I can do a much better job than most filters just by looking at from/subject...
I am sure much I get is from having a Taj hotels loyalty card.
As I am sure you know your servers and domains are clean on
Dave
toggle quoted message
Show quoted text
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave
McGuire
Sent: 15 April 2020 21:40
To: [email protected]
Subject: OT, mail issues, was Re: [h390-vm] memset help
On 4/15/20 2:07 PM, Peter Coghlan wrote:
(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 into 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...) I am noticing this to an increasing degree as well. My assumption is that
Google, having spent years pushing "free" email services while making
money on the back end by using the information they mine from it, are now
trying to push yet more people to use gmail accounts.
My mail server predates the very existence of Google as a company by
many years, and has only been use as a spam relay once, a decade ago, for
not quite a day, until I noticed that one of my hundred-or-so users
passwords had been cracked. The only reason I can see for email originating
from my server to be considered spam by Google is that it comes from a non-
gmail server.
This is just my assumption; I have no evidence to suggest that this is why
this is happening, it but it is the only explanation that I've been able to come
up with for this widespread and rapidly growing problem.
This is what happens when people take the lazy or cheap route and get a
"free" email account from a for-profit corporation. Google occasionally does
good things for society, but they are not a charity.
As many have said, and almost nobody actually pays attention to: If you
receive value from a corporation for free, you are the product.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
|
Mark,
No doubt ... but MVCL/E are still millicode instructions. MVC is a hardware instruction.
Joe
On Wed, Apr 15, 2020 at 4:28 PM Mark L. Gaubatz via <mgaubatz= [email protected]> wrote: Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ? ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: 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.
>
Drew,
This is very interesting given our recent discussion on the matter.
(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
into 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...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Joe: ? $MVCL was written many, many years ago. At the time, it was faster on certain machines. Need to re-validate this claim. ? Also, at the time the macro was written, the cachelines were shorter. On several machines, MVCL performed additional checks whenever crossing a cacheline. On others, it was at page boundaries. Consequently, on some machines, $MVCL was faster, on others, slower. It entirely depends on the underlying firmware and hardware implementing the two instructions. ? So please remember, some of the ¡°official¡± text when referring to performance is long outdated. ? Mark ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Joe Monk Sent: Wednesday, April 15, 2020 11:32 AM To: [email protected]Subject: Re: [h390-vm] memset help ? Even IBM admits that multiple?MVCs are faster than MVCL... "Use $MVCL to generate a MVC (move character) instruction when you need to move more than 256 bytes of storage. Use this macro instruction in high performance areas because multiple MVCs (as created by this macro) are faster than using an MVCL instruction." ? On Wed, Apr 15, 2020 at 1:11 PM Peter Coghlan <groups@...> wrote: 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.
>
Drew,
This is very interesting given our recent discussion on the matter.
(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
into 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...)
Regards,
Peter Coghlan
> --
> Drew Derbyshire
>
> "All right, Mr. DeMille, I'm ready for my close-up." -- "Sunset Blvd.,"
>
>
|
Dave McGuire