ときどきの雑記帖 RE* (新南口)
Damask Rose
ダロス
- 鳥海永行×押井守の「ダロス」が初Blu-ray化、EMOTIONレーベルの40周年記念し(動画あり) - コミックナタリー
- ダロス:世界初のOVAが初BD化 押井守監督監修のHDリマスター制作 EMOTION40周年 - MANTANWEB(まんたんウェブ)
懐かしい。 ただこれ、「俺たちの戦いはこれからだ」エンドだったような記憶が。
Arithmometer
HNを見てたら
というのが目について、Arithmometer
ってナニ?
となったので元記事を見たり
ググったりした。
- From Arithmometer to Microprocessors | by Erik Engheim | Nov, 2022 | ITNEXT
- Arithmometer - Wikipedia
- アリスモメーター(標準画像) | 博覧会―近代技術の展示場
- aris meter keisanki
- 機械式計算機 - Wikipedia
- 機械式計算機の計算外の歴史 | Nota Bene | Eugene Kaspersky Official Blog in Japanese
へー。
GNU sed 4.9
もうちょっと待てば GNU spotlightで知ったのだろうけど、 sed.git - GNU stream editor を見てGNU sedの4.9がリリースされていたのに気づく。
それじゃあと変更点をざっと見てみた。
NEWS - sed.git - GNU stream editor
* Noteworthy changes in release 4.9 (2022-11-06) [stable]
** Bug fixes
‘sed –follow-symlinks -i’ no longer loops forever when its operand is a symbolic link cycle.
[bug introduced in sed 4.2]
a program with an execution line longer than 2GB can no longer trigger an out-of-bounds memory write.
using the R command to read an input line of length longer than 2GB can no longer trigger an out-of-bounds memory read.
In locales using UTF-8 encoding, the regular expression ‘.’ no longer sometimes fails to match Unicode characters U+D400 through U+D7FF (some Hangul Syllables, and Hangul Jamo Extended-B) and Unicode characters U+108000 through U+10FFFF (half of Supplemental Private Use Area plane B).
[bug introduced in sed 4.8]
I/O errors involving temp files no longer confuse sed into using a FILE * pointer after fclosing it, which has undefined behavior in C.
シンボリックリンクのは別としてちょっと詳細が気になるな、
** New Features
The ‘r’ command now accepts address 0, allowing inserting a file before the first line.
あー、なんかこれ(先頭に別ファイルの内容を挿入)以前苦労したような気がする。
** Changes in behavior
Sed now prints the less-surprising variant in a corner case of POSIX-unspecified behavior.
Before, this would print “n”. Now, it prints “X”:printf n | sed 'sn\nnXn'; echo
ん、POSIX-unspecified behavior
?
あー、nを区切り文字にしたときに、
区切り文字でないようにするために\
を前置すると改行(\n
)と被るのをどうするのか。
って話か。
どんな修正だろうかというのを確かめてみたくなったので コミットの一覧から探すとこの辺かな。
- sed: fix infloop with symlink cycles
- sed: handle very long execution lines (tiny change)
- sed: handle very long input lines with R (tiny change)
- sed: allow ‘0rFILE’ (insert FILE before the first line)
- sed: handle the unspecified “n as delimiter alias” case more sensibly
最後のを見ると
diff --git a/sed/compile.c b/sed/compile.c
index 1942f3b..f96fbca 100644
--- a/sed/compile.c
+++ b/sed/compile.c
@@ -557,8 +557,6 @@ match_slash (int slash, int regex)
ch = inchar ();
if (ch == EOF)
break;
- else if (ch == 'n' && regex)
- ch = '\n';
else if (ch != '\n' && (ch != slash || (!regex && ch == '&')))
add1_buffer (b, '\\');
}
…え?
compile.c\sed - sed.git - GNU stream editor
while ((ch = inchar ()) != EOF && ch != '\n')
{
const int mb_char = IS_MB_CHAR (ch, &cur_stat);
if (!mb_char)
{
if (ch == slash)
return b;
else if (ch == '\\')
{
ch = inchar ();
if (ch == EOF)
break;
else if (ch != '\n' && (ch != slash || (!regex && ch == '&')))
add1_buffer (b, '\\');
}
else if (ch == OPEN_BRACKET && regex)
{
add1_buffer (b, ch);
ch = snarf_char_class (b, &cur_stat);
if (ch != CLOSE_BRACKET)
break;
}
}
add1_buffer (b, ch);
}
元々\
とn
の並びだけを特別視して
ch = '\n';
のようなことをしていたのか。
追記
sedの修正履歴で、バグフィックスの一覧にはある 正規表現関連のものが見当たらなかったのだけど、 考えてみればregexライブラリはgnulibのものを使っているんだから 探すならそっちだよな。
ということでgnulibのコミットログを探すと…これかな?
dfa: fix bug with ‘.’ and UTF-8 Hangul Syllables
This fixes a bug introduced in 2019-12-18T05:41:27Z!eggert@cs.ucla.edu, an earlier patch that fixed dfa.c to not match invalid UTF-8. Unfortunately that patch had a couple of typos when dfa.c is matching against the regular expression ‘.’ (dot). One typo caused dfa.c to incorrectly reject the valid UTF-8 sequences (ED)(90-9F)(80-BF) corresponding to U+D400 through U+D7FF, which are some Hangul Syllables and Hangul Jamo Extended-B. The other typo caused dfa.c to incorrectly reject the valid sequences (F4)(88-8F)(80-BF)(80-BF) which correspond to U+108000 through U+10FFFF (Supplemental Private Use Area plane B).
- lib/dfa.c (utf8_classes): Fix typos.
- tests/test-dfa-match.sh: Test the fix.
diff --git a/lib/dfa.c b/lib/dfa.c
index a27d096..e88fabb 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -1704,7 +1704,7 @@ add_utf8_anychar (struct dfa *dfa)
/* G. ed (just a token). */
/* H. 80-9f: 2nd byte of a "GHC" sequence. */
- CHARCLASS_INIT (0, 0, 0, 0, 0xffff, 0, 0, 0),
+ CHARCLASS_INIT (0, 0, 0, 0, 0xffffffff, 0, 0, 0),
/* I. f0 (just a token). */
@@ -1717,7 +1717,7 @@ add_utf8_anychar (struct dfa *dfa)
/* L. f4 (just a token). */
/* M. 80-8f: 2nd byte of a "LMCC" sequence. */
- CHARCLASS_INIT (0, 0, 0, 0, 0xff, 0, 0, 0),
+ CHARCLASS_INIT (0, 0, 0, 0, 0xffff, 0, 0, 0),
};
/* Define the character classes that are needed below. */
こういうのもtypo
って表現するんだ。
んで発端の修正はこれか。 dfa: do not match invalid UTF-8
GNU C Language Intro and Reference
c-intro-and-ref.git - GNU C Language Intro and Reference のコミットを見るとこれを書いている時点では10月上旬のものが最後で、 これ以上の変更、特に大きなものはなさそうということで、 熟読。は無理にしてもちょっと細かく見てみることにした。
GitHub - VernonGrant/gnu-c-language-manual でPDFが手に入るけど250ページかあ。
ま、それはさておき。 fp.texi の参考文献を挙げているところで
@c paywalled @item @c sort-key: Steele-2004 Guy L. Steele Jr. and Jon L. White, @cite{Retrospective: How to Print Floating-Point Numbers Accurately}, ACM SIGPLAN Notices @b{39}(4) 372--389 (April 2004), Reprint of 1990 paper, with additional commentary.
のように@c paywalled
のようなコメントがついているものがいくつかあって以下略
同じくfp.texiで、@ignore
~@end ignore
に囲まれて最終的なドキュメントには
出てこない部分に興味深いものを発見。
@ignore
@c =====================================================================
@node More on Decimal Floating-Point Arithmetic
c.texi
Decades ago, there were computers that used other representations for
signed integers, but they are long gone and not worth any effort to
support. The GNU C language does not support them.
なんでそうした(最終的な出力には表れないようにした)んだろうと思ったのだけど、 「入門」にはちょっと難度高めであるなどの判断があったらしい。
他には c.texi で
@sp 2
@ignore
WILL BE Published by the Free Software Foundation @*
51 Franklin Street, Fifth Floor @*
Boston, MA 02110-1301 USA @*
ISBN ?-??????-??-?
@end ignore
なんてのを見つけたのだけど、このあとの変更がないとして ある程度スケジュールは決まっているんだろうか気になった。
@ignore
@sp 1
Cover art by J. Random Artist
@end ignore
の人名にくすりとくるなど。
この続きは日を改めて書くかもしれないし書かないかもしれない。
bash
にあった話(バグ?)が興味深かったのでちょっと追いかけてみた。
まずは構文解析のところから…で
bash/parse.y
| LESS_LESS_LESS WORD
{
source.dest = 0;
redir.filename = $2;
$$ = make_redirection (source, r_reading_string, redir, 0);
}
これかな。
この部分は5.0と5.1で違いがないので、構文規則中で呼び出している
make_redirectionに対する引数のr_reading_string
を手掛かりにさらに潜ってみると、
実際にリダイレクトするときの関数呼び出しの流れが結構違っていた。
ざっとはこんな感じ。
5.0
here_document_to_fd
write_here_string
expand_string_unsplit_to_string
expand_string_to_string_internal (string, quoted, expand_string_unsplit)
expand_string_internal
call_expand_word_internal (&td, quoted, 0, (int *)NULL, (int *)NULL);
expand_word_internal
5.1
here_document_to_fd
heredoc_expand
expand_assignment_string_to_string
expand_string_to_string_internal (string, quoted, expand_string_assignment)
call_expand_word_internal
expand_word_internal
param_expand
parameter_brace_expand
here_document_to_fd のそれぞれの下位関数の呼び出し部分を比較するとこう。
5.0
/* write_here_document returns 0 on success, errno on failure. */
if (redirectee->word)
r = (ri != r_reading_string) ? write_here_document (fd, redirectee)
: write_here_string (fd, redirectee);
5.1.8
/* Expand the here-document/here-string first and then decide what to do. */
document = heredoc_expand (redirectee, ri, &document_len);
ふむ。 以前は二つの関数を呼び分けていたのを一つにまとめた? (heredoc_expand内部でごにょごにょしてるかもしれないけど)
Changelogからheredoc_expandやhere_document_to_fdに関する記述を 探してみるとこんなのが見つかった。
redir.c
- here_document_to_fd: if the shell compatibility level is bash-5.0 or
earlier, use tempfiles for all here-documents and here-strings. From
a bug-bash discussion started by Sam Liddicott
redir.c
- heredoc_expand: new function, called for both here-documents and
here-strings, takes care of expanding the document and returns a
string
- write_here_document: use heredoc_expand, call write(2) once on the
entire document; structure is now very similar to write_here_string
んでまあ変更点がたくさんあって どの変更がどうなのかは正直よくわからんのだけど(マテ)
今回のこの動作の変化はこの変更が影響してんじゃないかなあ。
subst.c
@@ -9371,4 +9688,10 @@ param_expand (string, sindex, quoted, ex
#endif
+ for (nullarg = 0, l = list; l; l = l->next)
+ {
+ if (l->word && (l->word->word == 0 || l->word->word[0] == 0))
+ nullarg = 1;
+ }
+
/* We want to flag the fact that we saw this. We can't turn
off quoting entirely, because other characters in the
@@ -9389,10 +9712,16 @@ param_expand (string, sindex, quoted, ex
/* XXX - what to do when in a context where word splitting is not
performed? Even when IFS is not the default, posix seems to imply
- that we behave like unquoted $* ? See below for how we use
- PF_NOSPLIT2 here. */
+ that we have to expand $@ to all the positional parameters and
+ separate them with spaces, which are preserved because word splitting
+ doesn't take place. See below for how we use PF_NOSPLIT2 here. */
/* These are the cases where word splitting will not be performed. */
if (pflags & PF_ASSIGNRHS)
- temp = string_list_dollar_at (list, (quoted|Q_DOUBLE_QUOTES), pflags);
+ {
+ temp = string_list_dollar_at (list, (quoted|Q_DOUBLE_QUOTES), pflags);
+ if (nullarg)
+ tflag |= W_HASQUOTEDNULL; /* we know quoting produces quoted nulls */
+ }
+
/* This needs to match what expand_word_internal does with non-quoted $@
does with separating with spaces. Passing Q_DOUBLE_QUOTES means that
changelog\CWRU - bash.git - bash
- param_expand: if IFS is not null, and we are expanding $* in a
context where we're not going to be performing word splitting, and
we quote a null string (resulting in a quoted null), make sure we
set W_SAWQUOTEDNULL to note this for the caller
バグフィックス(の副作用)なのか 意図した「仕様変更」なのかはよくわからんけど (投げっぱなしジャーマン)。
auto
C++のautoの誤用を検出したい - Qiita で紹介されていた コーディング規約 | Unreal Engine ドキュメント を見たらなんかよくわからない記述があったので(ry
‘auto’ キーワード
以下の例外がなければ、C++ コードで auto を使わないようにします。初期化している型について常に明示的でなければなりません。 つまり、読み手がその型を見えるようにしなければなりません。このルールは C# の ‘var’ キーワードの使用にも適用されます。
auto の使用はどのような場合に認められますか?
- lambda を変数にバインドする必要がある場合です。lambda 型はコードで表現できないからです。
- iterator 変数に対して認められます。しかし、iterator の型が非常に詳細で読みづらくなります。
- テンプレートのコードで認められます。この場合、式の型は簡単に見分けることはできません。これは高度な事例です。
コードの読み手に型がはっきり見えるようにすることは非常に重要です。一部の IDE では型を推測できますが、 これはコンパイル可能な状態にあるコードに依存します。merge/diff ツールのユーザーもサポートしません。 または、GitHub 上など各ソース ファイルを別個に見る場合などもサポートしません。
認められる方法で auto を使う場合、型名で使うように常に正しく const、 & または * を使うようにしてください。
auto
を使うと、推測された型を希望の型にします。
特に「これは高度な事例です」あたりが引っかかったので 原文であろう Coding Standard | Unreal Engine 4.27 Documentation をみると
The ‘auto’ Keyword
You shouldn’t use auto in C++ code, although a few exceptions are listed below. Always be explicit about the type you’re initializing. This means that the type must be plainly visible to the reader. This rule also applies to the use of the var keyword in C#.
When is it acceptable to use auto?
- When you need to bind a lambda to a variable, as lambda types are not expressible in code.
- For iterator variables, but only where the iterator’s type is verbose and would impair readability.
- In template code, where the type of an expression cannot easily be discerned. This is an advanced case.
It’s very important that types are clearly visible to someone who is reading the code. Even though some IDEs are able to infer the type, doing so relies on the code being in a compilable state. It also won’t assist users of merge/diff tools, or when viewing individual source files in isolation, such as on GitHub.
If you’re sure you are using auto in an acceptable way, always remember to correctly use const, & or * just like you would with the type name. With
auto
, this will coerce the inferred type to be what you want.
ふむ。
nullptr
autoの項のすぐ上にあったnullptrも
nullptr
すべての場合において、C-style NULL マクロの代わりに nullptr を使うようにします。
唯一の例外は、 C++/CX ビルド (Xbox One など) nullptr が実際には null 参照型によって管理されることです。 型といくつかのテンプレートのインスタンス化のコンテキスト以外は、ネイティブ C++ の nullptr とほとんど互換性があります。 従って、互換性のためには、より一般的な decltype(nullptr) ではなく TYPE_OF_NULLPTR マクロを使用するべきです。
nullptr
nullptr should be used instead of the C-style NULL macro in all cases.
One exception to this is that nullptr in C++/CX builds (such as for Xbox One) is actually the managed null reference type. It is mostly compatible with nullptr from native C++ except in its type and some template instantiation contexts, and so you should use the TYPE_OF_NULLPTR macro instead of the more usual decltype(nullptr) for compatibility.
is actually the managed null reference type.
が
「実際には null 参照型によって管理されることです」
になっているのはちと引っかかる。
その後に続く文も、(nullptrに関して)ほぼ互換だけれども
例外があるのでマクロ(TYPE_OF_NULLPTR )を使った方が良い。
って話だと思うけど
この訳だとそれがわかりづらいような。
Mastering Emacs
- An Interview with Mickey Petersen, Author of Mastering Emacs | Hacker News
- An Interview with Mickey Petersen, author of Mastering Emacs
というのを見かけ、へーと思って検索してみたところ このMastering Emacsには日本語版もあるらしい(ただし最新版には追い付いていない?)
- Mastering Emacsのすすめと、意外と便利な数引数の話 - ブログのおんがえし
- Mastering Emacsの翻訳を手伝いました|にゃんだーすわん|pixivFANBOX
- Mastering Emacs is now available in Japanese - Mastering Emacs - どーでもいい日々
そこからさらに元サイトの別記事を見るとこんなのが。
Mastering Emacs is now available in Japanese - Mastering Emacs
If you’re a Japanese speaker, you can now read my book, Mastering Emacs, in Japanese. I owe all this hard work to AYANOKOJI Takesi and USAMI Kenta, two legendary Emacs hackers and writers in the Japanese Emacs community. There’s a large Emacs community in Japan but, unless you speak Japanese, you probably wouldn’t know that!
It’s easy to miss, but Emacs owes its superb Unicode and multilingual support to the Japanese National Institute of Advanced Industrial Science and Technology (AIST) who created (and maintained) a separate fork of Emacs called Nihongo (“Japanese”) Emacs, first created in 1987. Later it was wrapped up into a separate package called MULE (M-x find-library mule.)
MULE was merged into Emacs 20.1 in 1997 (C-u 20 C-h n to open the NEWS file from then and search for MULE), and it’s one of the few exceptions Richard Stallman and the FSF made to their ironclad rule that copyright must be assigned to the FSF. So there’s a bit of trivia for you.
So, once again, thanks to Takesi and Kenta for their hard work. If you own my book, you can download the translated version for free.
NEmacsとかMULEを知っているとは何者ですかい(大げさ)>Mastering Emacsの著者
- Mastering Emacs
- Keyboard Shortcuts every Command Line Hacker should know about GNU Readline - Mastering Emacs
FORTRAN Compiler on IBM 704
今回もわき道にそれた話題から。
Punched card - Wikipedia を見ていたらこんな記述を発見。
For example, on the IBM 701[61] and IBM 704,[62] card data was read, using an IBM 711, into memory in row binary format. For each of the twelve rows of the card, 72 of the 80 columns would be read into two 36-bit words; a control panel was used to select the 72 columns to be read. Software would translate this data into the desired form. One convention was to use columns 1 through 72 for data, and columns 73 through 80 to sequentially number the cards, as shown in the picture above of a punched card for FORTRAN. Such numbered cards could be sorted by machine so that if a deck was dropped the sorting machine could be used to arrange it back in order. This convention continued to be used in FORTRAN, even in later systems where the data in all 80 columns could be read.
(https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_format_and_character_codes)
73桁目から80桁目はFORTRAN以前からパンチカードの管理番号などを記述するのに使われていて (自動でソートするマシンがあったとかスゲーな。別の記事で番号を振る機械もあったというのを 読んだ覚えがある。どこだっけ?🤔)、 FORTRANのソースコードを記述するのにもそれが影響して 72桁目までが有効にされていたと。
SECTION 1 / STATEA
さて、以前にも触れていたと思うけど、コンパイラー本体の入り口はこの辺で
REM SECTION 1 / STATEA = 4F11556
REM 704 FORTRAN MASTER RECORD CARD / STATE A = F0190000. 4F11557
ORG 0 4F115571
PZE ORGA,,DMWR09 4F115572
PZE ENDA-1 4F115573
REM 4F11558
REM NAME FUNCTION 4F11559
REM PART 1 / ASSEMBLE AND CLASSIFY ALL STATEMENTS= 4F11560
REM CA000 ASSEMBLE STATEMENT. 4F11561
REM CD000 SCAN FOR HOLLERITH AND ILLEGAL CHS.4F11562
REM CB000 CLASSIFY=ARITHMETIC/NON-ARITHMETIC.4F11563
REM CC000 CLASSIFY=WHICH NON-ARITHMETIC. 4F11564
REM PART 2 / PROCESS CONTROL AND SPECIFICATION STATEMENTS. 4F11565
実際、ファイルの先頭から見ていったときに
DMWR99 TSX CA100,4 * GO TO SUBROUTINE TO LOAD FT REGION.4F11540
TRA CA010 * GO BEGIN STATE A OF SECTION ONE. 4F11541
REM END OF INITIALIZATION / PART 2. 4F11542
なんてのも見つかる。ただ先のコメントにあったCA000
ってラベルはなくて、
CA010
から始まっているのは謎。
それじゃあということで区切りのいいところまでを見るとこんな感じ。
REM STATEA/1-ASSEMBLE AND CLASSIFY ALL STATEMENTS= 4F11637
ORGA ORG 1824 4F11638
REM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *4F11639
REM 4F11640
REM CA000/ CALLS=CA100,SR6DC1,TET00,DIAG. 4F11641
REM CA000 ASSEMBLES STATEMENT IN THE F-REGION AND ASSIGNS AN IFN.4F11642
CA010 LXD ENDWRD,4 IF THE FINAL STATEMENT HAS BEEN 4F11643
TXL DIAG,4,0 * PROCESSED, THE GO CALL DIAGNOSTIC. 4F11644
LXD EIFNO,1 KEEP INTERAL FORMULA NUMBER 4F11645
TXI CA013,1,1 (DECR PART OF EIFNO) 4F11646
CA013 SXD EIFNO,1 UP TO DATE BY ADDING 1. 4F11647
CAL FT OBTAIN HOLLERITH CODED 5-DIGIT 4F11648
ARS 6 EXTERNAL FORMULA NO IN ACC. 4F11649
SLW F-1 AND RETAIN IN F-01. 4F11650
LXD DCF,1 INITIALIZE INDEX A TO COMPL OF F. 4F11651
CA018 LXA L(11),2 SET UP LOOP FOR 11 CYCLES. 4F11652
CA019 LDQ FT+12,2 MOVE WORD FROM REGION FT 4F11653
STQ 0,1 TO REGION F. 4F11654
TIX CA020,1,1 KEEP F-REGION ADDRESS UP-TO-DATE. 4F11655
CA020 TIX CA019,2,1 TEST END OF LOOP. 4F11656
TSX CA100,4 * GO READ NEXT NON-BLANK CARD. 4F11657
CAL FT TEST RIGHTMOST CHARACTER OF 4F11658
ANA L(63) FIRST WORD FOR CONTINUATION MARK, 4F11659
TZE CA021 IF ZERO OR BLANK, 4F11660
SUB ABLANK DISCONTINUE READING, 4F11661
TNZ CA018 OTHERWISE CONTINUE. 4F11662
CA021 CLA BLANKS BEGIN SCANNING REGION F BACKWARDS 4F11663
CA022 CAS -1,1 TO FIND FIRST NON BLANK WORD. 4F11664
TRA CA023 NOT BLANK. 4F11665
TXI CA022,1,1 BLANK, SO CONTINUE SCAN. 4F11666
CA023 LDQ 36ONES PLACE BINARY ONES IN FIRST WORD 4F11667
STQ 0,1 FOLLOWING RIGHTMOST NONBLANK WORD. 4F11668
CAL F-1 PICK UP EXTERNAL FORMULA NUMBER AND4F11669
CAS 5BLANS COMPARE WITH /0 /. 4F11670
TRA CA015 NOT COMPARE. 4F11671
TRA CD000 * TAKE EXTFORMNO, IF ANY AND 4F11672
CA015 LRS 35 GO TO CONVERSION SUBROUTINE AND 4F11673
TSX SR6DC1,1 * RETURN HERE WITH RESULT IN ACC. 4F11674
STA EIFNO STORE RESULT IN ADDRESS OF EIFNO. 4F11675
TSX TET00,1 * GO TO PROGRAM TET TO ENTER EIFNO 4F11676
PZE 0 INTO TABLE TEIFNO (TABLE O). 4F11677
REM END OF PROGRAM CA000. 4F11678
まあ短いと言えば短いといった分量ではある。 ここで登場するラベルで「外部」の呼び出しなどのものは以下の通り
- CA100
- SR6DC1
- TET00
- DIAG
- CD000
最後の一つ(CD000)は次の処理 (SCAN FOR HOLLERITH AND ILLEGAL CHS.) の入口で、その他はサブルーチン。
データに関するラベルは以下の通り
- ENDWRD
- EIFNO
- FT
- F
- DCF
- L(11)
- FT
- L(63)
- ABLANK
- BLANKS
- 36ONES
- 5BLANS
なんだけど、一か所に固められていなかったり
DCF TXI C0180,0,-F REPEAT PROCESS FOR NEXT CHARACTER. 4F10528
のようにコード中に埋め込まれていたりで 追いかけるのがなかなか面倒。
F
前述のラベルの中のF
について。
一文字のラベルとかなんて検索しづらいものをとぶーたれながら 探してみると
>grep -e "^ *F " fort1.asm
F BSS 111 ASSEMBLED STATEMENT REGION. 4F10282
F SYN 618 ADDRESS OF 1ST WORD OF F REGION 4F1D4640
F CLA ZERO SET INDICATOR TO SAY F5G14810
F BSS 111 ASSEMBLED STATEMENT REGION. 4F10282
F CLA ZERO SET INDICATOR TO SAY F5G14810
F BSS 1 VARIABLE USED BY DBC. DBC/587
F BCD 100000F CCTEST-2. BDC/576
F EQU -2 F2EXP052
F EQU -2 F2TNH096
F TXL G,2,-6
F TXL G,2,-4
なんでこう同じ名前を複数使うかなあ
(たぶん「別のファイル」なんでそうなったんだろうけど)。
まあそれはさておき今回関係するのは多分ここ。
コード中ではF-1
のような参照をされていたりもするので
直前のラベルも合わせて。
EFN BSS 1 EXTERNAL FORMULA NUMBER (F-1). 4F10281
F BSS 111 ASSEMBLED STATEMENT REGION. 4F10282
コメントに出てくるF-REGION
やREGION F
というのはこれのことらしい。
あとでかく(かもしれない)
- その1
- その2
- その3
- その4
本日、勤労感謝の日は2022年最後の祝日だそうです㊗️ pic.twitter.com/DwjauDJUDG
— ナイセン®︎【公式】🏆テレワークに役立つサービス No.1 (@itallinc) November 22, 2022