Sekiz Karakter: Berkeley SoftFloat'ı MVS 3.8j'ye Taşımak

1981 tarihli bir işletim sistemi, dışa açık bir sembole en fazla sekiz karakter verir ve harfleri büyük olmak zorundadır. Berkeley SoftFloat ise fonksiyonlarını softfloat_roundPackToF64 gibi adlandırır. ONFLY ikisine de mecbur; uzlaştırma, Hercules emülatöründeki MVS 3.8j üzerinde ölçülmüş üç ayrı hataya mal oldu.

Sirkesineği beyni simülasyonu neden kendi kayan noktasını taşıyor

ONFLY, bir sirkesineğinin besleme devresini anabilgisayar iş yükü olarak çalıştırıyor ve aynı isteğin hedeflediği her platformda aynı parmak izini üretmesini şart koşuyor. Donanım aritmetiği bunu S/370 onaltılık kayan nokta ile IEEE ikili biçim arasında sağlayamaz, bu yüzden motor IEEE 754'ü yazılımda gerçekliyor.

Hangi sürümü kullanacağınızı belirleyen kısıt, kütüphanenin kendi sayfasında yazıyor. Release 3'ten beri SoftFloat C'de 64 bitlik bir tamsayı tipine bağımlı; böyle bir tipi olmayan derleyiciler 32 ve 64 bitlik biçimler için eski Release 2c'ye yönlendiriliyor (Berkeley SoftFloat).

GCCMVS tam olarak böyle bir derleyici: 64 bitlik bir tipi var ama onu güvenilir biçimde derleyemiyor. TK5 üzerinde ölçüldüğünde 64 bitlik tamsayılarda dört bağımsız biçimde başarısız oldu: dört ayrı noktada iç derleyici hatası, sessizce yanlış sonuç veren değişken kaydırmalı 64 bit sola kaydırma, PDPCLIB'de 64 bit çalışma zamanı yardımcılarının bulunmaması ve bunları yanlış biçimde isteyen bir kod üretimi hatası. Release 2c'nin bits32 derlemesi bir float64'ü iki 32 bitlik yarım olarak taşıyor ve hiçbir yerde 64 bitlik tamsayı oluşturmuyor.

Tek bir PDS üyesine çözümlenen üç include adı

GCCMVS, #include "ad" ifadesini adın ilk sekiz karakterinden oluşan PDS üyesine çözümler: büyük harfe çevrilmiş, noktalama ve uzantı dahil. 11 Eylül 2026'da TK5 üzerinde, tek bir SOFTFLOA üyesine karşı ölçüldü. "softfloat.h", "softfloat-macros", "softfloat-specialize" ve "softfloa.h" yazımlarının dördü de aynı üyeye çözümlendi, dönüş kodu 0.

Release 2c'nin bits32/softfloat.c dosyası bu adlardan üçünü birden include ediyor ve üç dosya tek bir üyeye sığmaz. DD tanımında birden fazla kütüphaneyi art arda vermek de kurtarmıyor, çünkü MVS üyeyi ona sahip ilk kütüphaneden alır. Dosyaları yeniden adlandırmak ise kapalı bir kapı: third_party/ ağacı, SHA-256 özetleri kayıtlı upstream arşivleriyle bayt bayt aynı kalmak zorunda.

GCC'nin -remap seçeneği zaten çok kısa adlı dosya sistemleri için var, yani tam bu duruma. Bu portta kabul ediliyor ve hiçbir etkisi olmuyor. Derleme bunun yerine birleştirme yapıyor: include'lar gönderim anında sırayla satır içine alınıyor ve diske hiç yazılmıyor, böylece kaynaktan sapabilecek ikinci bir kopya oluşmuyor.

Assembler XF'in 42 sembolün 38'i hakkında söyledikleri

Include sorunu çözüldükten sonra Release 2c dönüş kodu 0 ile derlendi ve assembler çıktıyı reddetti:

IFO196  FLOAT64@ HAS BEEN PREVIOUSLY DEFINED
IFO196  FLOAT32@ HAS BEEN PREVIOUSLY DEFINED
IFO196  INT32@TO HAS BEEN PREVIOUSLY DEFINED
IFO189  INVALID ENTRY OPERAND, LINKAGE CANNOT BE PERFORMED

Sekiz karaktere kırpıldığında Release 2c'nin 42 dışa açık adından 38'i üç çakışma grubuna düşüyor: on sekiz float32_*, on sekiz float64_* ve iki int32_to_*. Kütüphaneyi ayrı derleme birimlerine bölmek çakışmayı assembler'dan linkage editor'e taşımaktan öteye gitmiyor.

Çözüm, her dışa açık ada uyumlu bir karşılık veren üretilmiş bir #define önsözü. Bu önsöz x86'da da uygulanıyor, böylece yeniden adlandırma mekanizmasını olağan test paketi çalıştırıyor ve keşfi MVS'e bırakılmıyor.

#define ile yeniden adlandırılamayan, silinecek olan beş ad

Aynı işlem, lint'in hiçbir istisna olmadan zorlayabilmesi için Release 3e'ye de uygulandı ve çakışan on üç adından beşi bunu kaldıramadı. Her biri hem primitives.h içinde hem de kendi kaynak dosyasında #ifndef <ad> biçiminde yazılmış. Bu, yukarı akımın belgelenmiş genişletme noktası: adı tanımlamak "bu fonksiyonu platform sağlıyor" demek, ve yukarı akım hem bildirimi hem tanımı atlıyor.

Yeniden adlandırma amaçlı bir makro dolayısıyla o beş fonksiyonu silerdi. ONFLY genişletme noktasını tasarlandığı gibi kullanıyor: softfloat/onfprim.c yukarı akımın kendi gövdelerini uyumlu adlar altında, bir betikle mekanik olarak türetilmiş halde taşıyor ve third_party/ hiç ellenmiyor.

Bir fonksiyon gövdesini kopyalamak, kopyanın aynı davrandığını kanıtlamaz. Kanıt, ardından koşulan test paketi: iki backend'de 520.752 TestFloat vakası, 449 kernel adımı ve bunların hiçbiri yokken hesaplanmış 13 altın kabul parmak izi; hepsi değişmeden çıktı (VL-28).

SoftFloat'ın çakışmalarını listeleyip zorlamayan lint

Projenin C-04 lint'i, port başlamadan önce de SoftFloat'ın sekiz karakteri aşan sembollerini listeliyordu, ama yalnızca ONFLY'ın kendi adlarında ihlal sayıyordu. Release 2c'nin Assembler XF'e kadar fark edilmeden ulaşması bu yüzden oldu. Artık zorluyor ve yeniden adlandırılmamış nesne üzerinde çalıştırıldığında assembler'ın bulduğu üç grubun aynısını üretiyor.

Lint, çakışmayı daha hiçbir iş gönderilmeden yakalıyor. GCCMVS dışa açık adları sekiz karaktere kırpıp büyük harfe çevirdiği için, yalnızca sekizinci karakterden sonra ya da yalnızca büyük küçük harf bakımından farklılaşan iki ad tek bir sembole dönüşür ve Assembler XF bu çifti reddeder (VL-25).

İki sürümün uyumu x86 üzerinde, ikisi de aynı Berkeley TestFloat vektörlerinden geçirilerek sınandı: altı işlemde 260.376 vaka, sıfır uyuşmazlık, 18.408 NaN vakası hariç. TestFloat beklenen sonuçları SoftFloat'ın kendisiyle hesaplıyor (TestFloat) ve ONFLY'ın üreteci değiştirilmemiş bir Release 3e derlemesine bağlı; yani koşu, 2c'nin TestFloat vektörlerinde 3e'nin aritmetiğini birebir verdiğini gösteriyor.

MVS üzerinde bugüne kadar gerçekten derlenenler

Önce kayan nokta kütüphanesi ve üç test sürücüsü geldi. 11 Eylül 2026'da GCCMVS, ONFLY'ın motor birimlerini de Hercules altındaki MVS 3.8j TK5 üzerinde derledi ve decode'dan simülasyona, oradan parmak izine kadar tüm motor yolu orada doğru çalıştı (VL-31, VL-35). MVS üzerindeki TestFloat koşusu ise x86'daki 260.376 vakaya karşılık 4.500 vaka kapsıyor; akış boyunca katmanlı örneklenmiş olsa da bir örneklem.

Dört geçici çözüm taşıyıcı durumda: iki ayrı derleyici hatasının arasından geçen -O1 sabitlemesi, Hercules'in 819/1047 kod sayfası, include birleştirmesi ve sembol yeniden adlandırmaları. Sabitleme, birleştirme ve yeniden adlandırmalar depoda, tools/mvsbld.py içinde ve üretilmiş bir başlık dosyasında duruyor; kod sayfası ise ana makine yapılandırması ve Hercules yeniden başlatılınca sessizce eski haline dönüyor, bu yüzden gönderim aracı böyle bir durumda işi göndermeyi reddediyor.

ONFLY'ın adı o tarihten bu yana FlyBatch; -O1 sabitlemesinin de daha sonra kendine ait sessiz bir yanlış derleme taşıdığı ortaya çıktı, ayrıntısı MVS'te 19 Parmak İzi Tuttu, Sıfır Yine de Yanlıştı yazısında.

PDS tabanlı bir araç zincirine bir şey taşıyorsanız, FlyBatch deposundaki C-04 lint'ini ve yeniden adlandırma üreteçlerini inceleyin; sekiz karakter kuralı sizi test paketinizden önce bulacak.