|
查看上一个主题 :: 查看下一个主题
|
| 作者 |
信息 |
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
在CICS论坛中，该文章提到了GETMAIN和FREEMAIN宏的使用，然后继续声称STORAGE宏更快。这是个谎言。
以下程序产生了这些消息-
所需存储时间比一般/普通多10％
GETMTIME = 6.540824，STORTIME = 7.228047
| 码： |
最佳技术交流
USING *,12
SAVE (14,12),,*
LR 12,15
LA 15,SAVEAREA
ST 13,4(,15)
ST 15,8(,13)
LR 13,15
TIMEUSED STORADR = GETMSTRT，CPU = MIC，LINKAGE = SYSTEM
L 2,=A(64*1024)
LA 3,128
GETMLOOP GETMAIN RU，LV =(3)
MVC 0(4,1),GETMHDR
ST 1,GETMHDR
BCT 2,GETMLOOP
自由循环ICM 1,B'1111',GETMHDR
BZ GETTIME
MVC GETMHDR,0(1)
FREEMAIN RU,LV=(3),A=(1)
B FREELOOP
GETTIME TIMEUSED STORADR = GETMEND，CPU = MIC，LINKAGE = SYSTEM
L 2,=A(64*1024)
目标 储存空间，长度=(3)
MVC 0(4,1),GETMHDR
ST 1,GETMHDR
BCT 2,OBTGET
过时的 ICM 1,B'1111',GETMHDR
BZ OBTTIME
MVC GETMHDR,0(1)
存储释放，长度=(3),ADDR=(1)
B OBTFREE
OBTTIME TIMEUSED STORADR = OBTEND，CPU = MIC，LINKAGE = SYSTEM
LG 1,GETMEND
SG 1,GETMSTRT
STG 1,GETMTIME
LG 0,OBTEND
SG 0,STORSTRT
STG 0,STORTIME
SGR 1,0
SR 0,0
M 0,=F'100'
D 0,GETMTIME+4
ST 1,PERCENT
CVD 1,DWORK
ED PCT,DWORK+6
L 1,GETMTIME+4
CVD 1,DWORK
* 3 4 5 6 7
* NNNNNNNNN
ED GETMD,DWORK+3
L 1,STORTIME+4
CVD 1,DWORK
ED 储存,DWORK+3
OPEN (PRINT,OUTPUT)
PUT PRINT,MSG
PUT PRINT,MSG2
CLOSE 打印
L 13,4(,13)
RETURN (14,12),RC=0
保存AREA DC 9D'0'
GETMSTRT DC FD'0'
GETMEND DC 0FD'0'
STORSTRT DC FD'0'
OBTEND DC FD'0'
GETMTIME DC FD'0'
STORTIME DC FD'0'
作品 DC PL8'0'
百分 DC F'0'
GETMHDR DC A(*-*)
打印 DCB DSORG = PS，MACRF = PM，DDNAME = SYSPRINT，RECFM = VBA，LRECL = 126
DC 0D'0'
LTORG ,
味精 DC AL2(MSGL,0)，C'需要存储'
PCT DC 0C'NNN'，C''，X'202120'，C'％比GETMAIN / F多的CPU时间>
REEMAIN'
味精L EQU *-MSG
味精2 DC AL2(MSG2L,0),C' GETMTIME ='
GETMD DC 0C'NNN.NNNNNN'，C''，X'202120'，C'。'，6X'20'，C'，'
DC C'STORTIME ='
储存 DC 0C'NNN.NNNNNN'，C''，X'202120'，C'。'，6X'20'
味精2L 均衡器 *-MSG2
END GETMTEST
|
该程序在Hercules（而不是真正的硬件）下运行。在普通的z / Arcitecture机器上运行它会很有趣，尽管我怀疑有人会打扰。 |
|
| 回到顶部 |
|
 |
UmeySan
活跃的成员
已加入：2006年8月22日
职位：771
地点：德国
|
|
|
|
@史蒂夫
就个人而言，随着今天的那些mi，我不会或多或少浪费时间。
此致UmeySan
从IBM：
z / OS MVS编程：授权汇编程序服务指南
SA22-7608-17
是否使用GETMAIN或STORAGE OBTAIN来获取虚拟存储以及使用FREEMAIN或STORAGE RELEASE来释放存储的决定取决于几个条件：
程序的地址空间控制（ASC）模式。如果它处于AR模式，请使用STORAGE宏。
包含程序要获取或释放的存储的地址空间。如果存储位于主存储区以外的地址空间中，请使用STORAGE宏。
程序是否需要宏服务的分支条目或PC堆栈条目。使用GETMAIN或FREEMAIN宏上的分支条目比使用STORAGE宏更困难。因此，您可以使用STORAGE OBTAIN而不是GETMAIN来简化编码，例如，当您的程序：
处于SRB模式
处于交叉存储模式
以启用的，未锁定的任务模式（EUT）FRR运行
分支条目（GETMAIN或FREEMAIN上的BRANCH参数）要求您的程序持有某些锁。存储没有任何锁定要求。
如果您的程序在可以发出FREEMAIN宏的环境中运行（由上面列出的条件指定），则可以使用FREEMAIN释放最初使用STORAGE OBTAIN获得的存储。您也可以使用STORAGE RELEASE释放最初使用GETMAIN获得的存储。 |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
好吧，当然，您的决定取决于很多事情。
很多时候，决策取决于是否可以采用某种机制来完全避免使用MVS存储管理。例如，我的大多数私人服务功能都要求调用者提供一个较小的工作区（如100或200字节），或者通过最小化寄存器使用量，将调用者提供的寄存器保存区的一部分用作工作区。在这里，有关存储管理的决定将推迟到其他代理！
几年前，我有一个程序（就像我的测试程序一样）分配了成千上万个小存储区，这些存储区在程序结束时成块释放。在测试过程中，该过程似乎需要很长时间，因此我在测试程序中使用TIMEUSED对其进行了检测，发现它使用了将近一分钟的CPU时间！当时我的解决方案是清除私有功能，该功能会在较大的4K存储块中分配很少的存储区域，最后将这些4K块释放为一组。一分钟的CPU时间降到了不到一秒！
几年前，当BAKR指令发布为IBM“标准”子例程进入/退出约定的可能替代品时，我尝试了一下，发现它更糟！经过一番思考，我意识到它在ESA 390中保存了16个32位寄存器和16个32位访问寄存器。在z / Architecture中，它保存了16个64位寄存器和16个32位访问寄存器。感谢IBM，我将坚持使用常规机制！
在1990年代与XPLINK的开发相关的精美记录中，您会注意到没有提到BAKR，这无疑是我在较早的测试中开发的原因。 XPLINK确实指出了“标准”链接约定需要太多的寄存器来保存和恢复，这是我现在在我自己的工作中考虑的事情，尽管这通常会释放少量的寄存器保存区存储以用作工作区。
就在上周，我研究了已经绝望的过时的Burrough B5500，这是1960年代非常创新的机器。讨论使我开始思考与我们现在看到的几乎通用的堆栈体系结构相比，面向寄存器的体系结构，例如System / 360。当时我的想法是，堆栈使用堆栈的一部分作为存储中的伪寄存器，在我看来，这比实际寄存器要慢。现在，我意识到堆栈体系结构没有大量的寄存器，因此可以简化（并因此加快）状态保存（例如在中断或子例程调用中），这可能就是为什么它们如此流行的原因。好吧，只是一个想法。 |
|
| 回到顶部 |
|
|
UmeySan
活跃的成员
已加入：2006年8月22日
职位：771
地点：德国
|
|
|
|
@史蒂夫
非常感谢您提供这些详细的说明。
就像您一样，几年前，IBM取消了有关64bit和z / Arch的一些新说明时，我拍了一些照片，但决定保留我的传统方法。
我认为不需要使用相对较大的目标分支指令
在编程时，例如BRAS / BRXH或ML / DL等乘法/除法
正常的商业应用，尽可能复杂。使用与COBOL中相同的认可技术-高度结构化-设计良好-进行编程。
正如我在您的个人资料中看到的那样，您是一位退休的专业人士。我深深的敬意，您仍然在忙于应用程序开发和系统工程。
我两年前已经退休，现在我又回来了一些有关汇编程序编程的移植项目。我有些上瘾。
特别是当获得可观的收入时。
对我来说，汇编程序并没有像很多年前宣布的那样全部消亡。德国大多数银行仍然有一些程序。
此致UmeySan |
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
1990年代，当相关分支指令问世时，我的分析主要受益者是编译器，与汇编程序程序员相比，编译器确实倾向于编写相对较大的代码块。比如说从2010年到2013年的几年中，我遇到了一个麻烦事，我只使用了相对的分支指令，但是我大多只是改用传统的BC指令。
1991年，当我失业了相当长的一段时间后，我学习了C语言，并学习了C qsort库函数功能。到1991年底，我回到了真实的机器上，再次使用了Assembler。 1993年，我写了QSORT。像qsort一样，它使用比较功能。不久之后，我意识到使用BRC指令不需要比较功能的基址寄存器，因此可以减少使用的寄存器，以及必须保存和恢复的寄存器。 XPLINK的阴影。 QSORT使用常规链接调用比较功能-
调用比较，（地址1，地址2）
使用QSORT的大多数程序会多次调用它，并具有多个比较功能。比较功能几乎使用了常见的启动顺序，通常-
保存 14
LM 14,15,0（1）
LR 1,15
洛杉矶15,1
*在此处插入比较代码。
寄存器15具有初始返回码，即qsort钉书钉-负，0，正，含义相同。
通常，所有比较功能都有一个共同的后缀
| 码： |
SC0100 SR 15,15
BRC 15,SC0300
SC0200 LNR 15,15
SC0300 RETURN 14,RC=(15) |
有时，当分支不小于或大于时，您会进入SC0100，SC0200或SC0300通常由JL SC0200或JH SC0300分支。比较功能对性能至关重要，因此我可以节省的一切都是朝着正确方向迈出的一步。我不保存和恢复寄存器0和1，因为QSORT不需要它们。 QSORT中的实际CALL宏是
LR R15，R5
呼叫（15），（（（R9），（R10）），MF =（E，PARMLIST）
宏会破坏寄存器14、15和1，QSORT实际上并不使用寄存器0。寄存器5具有比较例程的地址。显然，比较功能无法更改寄存器2至13，但是无论如何它都不会使用它们。
现在，如果比较功能需要其自己的基址寄存器，则其编码方式可能会不同
使用*，2
保存 (14,2)
LR 2,15
洛杉矶15,1
...
返回（14,2），RC =（15）
保存宏扩展为
+ STM 14,2,12（13）
相比
+ ST 14,12（，13）
RETURN扩展为
+ L 14,12（，13）
+ LM 0,2,20（13）
+ BR 14
相比
+ L 14,12（，13）
+ BR 14 |
|
| 回到顶部 |
|
|
彼得·荷兰
全球主持人
已加入：2009年10月27日
帖子：2476
所在地：荷兰，阿姆斯特尔芬
|
|
|
|
但是，您想证明什么？你做了一些编程吗？
对你有益。
| 引用： |
UmeySan
就个人而言，随着今天的那些mi，我不会或多或少浪费时间。
是的，他是对的。
|
|
|
| 回到顶部 |
|
|
史蒂夫·迈尔斯
活跃的成员
已加入：2013年11月30日
帖子：870
地点：宇宙
|
|
|
|
几分之一秒的确累加了。而且，令人惊讶的是，它们仅在大型机上被发现。在玩具和婴儿机器上，没有人试图测量这种东西，所以没有人在乎，因为无法测量。这是项目倾向于在玩具和婴儿机器上消耗更多气体的原因之一，因为没有人事先检查过。尽管测量工具的可重复性令人失望，但它们已经在大型机中使用了数十年，尽管实际使用它们的纪律似乎已经消失了，这可能是因为它不在CS课程中（因为不能在玩具和婴儿身上完成）这些人似乎依靠摩尔的“法律”掩盖自己的失误。
QSORT中的原始外壳并不是很好。其实我是从K那里偷来的&R，出于演示目的对其进行了简化。但是我可以通过在其他地方提高效率来部分弥补它，例如比较功能。
我试图证明的是您必须注意小东西。 ST 14比STM 14,2快很多。 L 14比L 14 / LM 0.2快得多。如果调用比较函数100,000次，您将看到不同。 |
|
| 回到顶部 |
|
|
UmeySan
活跃的成员
已加入：2006年8月22日
职位：771
地点：德国
|
|
|
|
你好史蒂夫
我认为这仍然是一场无休止的辩论。我仍然认为在大型和复杂的SQL语句的处理时需要密切注意一些不可避免的必要性。可能比某些汇编程序说明更关键。
可以用Strobe和Omegamon进行测量。
但是就像我说的那样，我不是在乎运行时字节数或几秒钟的家伙。我不再将位开关与TM一起使用。我认为没有必要在进行商业编程。几秒钟的付出或付出不会赢得胜利或金表。
祝您周末愉快，UmeySan
哥登达·彼得
Hartelijk dank即将成为主流。
Plezant weekeinde，groet，于梅山 |
|
| 回到顶部 |
|
|
彼得·荷兰
全球主持人
已加入：2009年10月27日
帖子：2476
所在地：荷兰，阿姆斯特尔芬
|
|
|
|
| 引用： |
哥登达·彼得
Hartelijk dank即将成为主流。 |
很好，非常感谢。
也祝您周末愉快。 |
|
| 回到顶部 |
|
|
|
|
  |
查看书签
所有时间均为格林尼治标准时间+ 6小时 |
|
