Endian (Byte-Order) meselesi?

[OsmanTuran]

Herkese merhaba,
Görüşmeyeli uzun zaman oldu sanırım. İş güç ben de ne cevap yazabiliyordum ne topic açıp kafamdaki soruları sorabiliyordum. Neyse 2005 yazının tarafımdan açılan ilk topic inde byte-order meselesiyle ilgili tuhaf bir soru soracağım siz değerli oy.org üyelerine

Efendim, şimdi diyelim bir oyun motoru yaptık. Bi de virtual file system gömdük sisteme interface ler yardımıyla. Sonracığıma tam otomasyon olsun diye MOD programcıları big-endian mı, yoksa little endian mı processor (PowerPC veya x86) bakılmaksızın ReadInt32, ReadInt16 gibi dosya sistemi fonksiyonları tanımladık VFS de. Lakin yaptığım araştırmalarda gözüme birşey takıldı. Var olan iki yöntem var (!) dosyadan hangi sistemde olunursa olunsun little byte order olarak okuma yapan:

1-Quake2 kodundaki gibi program açılışta bir swap testi yapar. Program buna göre swap kodlarının procedure/fonksiyon adreslerini set eder. Sonra sistem hiç birşey yokmuş gibi çalışıyor.
2-Programlayan adamların "Portable C++ blabla" dedikleri programlar hiç test yapmadan direk byte byte okutup bit-shifting lerle integer, word gibi ifadeler elde etme.

Örneğin:
function ReadInt32(Stream: TStream): Integer;
var buf: array[0..3] of Byte;
begin
Stream.ReadBuffer(buf[0], 4);
Result := buf[0] or (buf[1] shl or (buf[2] shl 16) or (buf[3] shl 24);
end;

Mesela, ben böyle bir fonksiyondan yanayım VFS içerisinde. Ama diğer koşullarda 1. yöntemi de kullanmayı düşünüyorum.

Şimdi ikinci yöntemle ilgili sizden iyi olmasin (www.glscene.org) forumuna bi topic actim adamlar kisaca böyle bişey olmaz diyor (Ivan efendi). Sizin yorumunuz nedir? İlla birinci seçenek olan Carmack amcadan kalma yöntemler mi uygulayalım? Ne dersiniz?
PS: Biraz uzun mu oldu ne?

[OsmanTuran]

Çok özür diliyorum. Şu winkler nerden çıktı yaw Şöyle olacak o satır

Result := buf[0] or (buf[1] shl 8 ) or (buf[2] shl 16) or (buf[3] shl 24);

[HakanNehir]

Delphiyle mi kullanacaksın bilmiyorum ama ben olsam birinciyi seçerdim.
Neden dersen hem daha hızlı hemde debug etmesi daha kolay.

Ama ikincisi de çalışır bir problem yok.

[lucifer]

>Program buna göre swap kodlarının procedure/fonksiyon
>adreslerini set eder.

Ben bu yonteme cok alistim, bizim gibi 50mhz'lik islemciyle 100,000 user desteklemeye kalktigin durumlarda optimal kod hayli onemli oluyor, bir cok yerde 'if' checklerini elimine etmek icin procedure pointerleri kullaniyoruz. ama zaten stream.ReadBuffer() cok zaman alacagi icin altindaki o check'in yedigi zaman ignore edilebilir.

bi de, o yazdigin procedure'nin mac'de duzgun calisacagina emin misin? sanki mac'de o result := satiri buf[3] or (buf[2] shl 8) ... gibi olacakti.... bir dusuneyim.... dusunemiyorum cok uykum var.

iyiki dondun osmanturaaaan, iyikidondun osmanturraaaann

[KePhReNZ]

Yanlış anlamadıysam her zaman LITTLE_ENDIAN okutmak istiyorsun ...

Bence iki tane header yapıp birisini BIG_ENDIAN sa , diğerini LITTLE_ENDIAN sa include etmek daha doğru olur , en azından ben böyle yapardım, hiç kullanmayacağım bir kodu niye hafızaya yükleyim 1, ikincisi (gerçi powerpc lerde war) little endian/big endian arasında switch yapmam gerekmeyecek.

Yani

#ifdef LITTLE_ENDIAN
okuFonk()
{
..........
}
#endif

#ifdef BIG_ENDIAN
okuFonk()
{
........
}
#endif

[OsmanTuran]

valla gec de olsa mesaj yazayim.

@lucifer: yaw iste ben de ondan emin degilim. O Result'in oldugu satir bana yanlis gibi geliyor. Ama hangi "portable c blabla" programina baksam little endian okutmak icin boyle yapiyor. Ayrica o kucuk delphi kodunu sadece file system de kullanmayi dusunuyorum. Diger yerlerde variable procedure kullanacagim. Aslinda delphi optimizasyonuna baktigimizda (eminim diger compiler larda da oyledir) variable bir procedure un cagrilmasinda bi suru push-pop lar beliriyor normal static procedure e oranla. Cogu zaman bir test yada cmp komutu (yani high-level deki if komutlari) daha hizli sonuclar veriyor.

Bu arada hosbulduk uğur bey

[leblebi]

Bu isi network codeunda da kullanman gerekecegi icin(non-real time file access icin performans o kadar onemli olmasa da network icin onemli olacaktir, tabii profile edip gormek lazim) on-the-fly swap yerine function pointer ya da call overhead derdin varsa KePhReNZin dedigi gibi kullanmak daha akilci bana gore.