Forum: D Programlama Dili RSS
C dilindeki gibi define
Sayfa:  önceki  1  2 
acehreli (Moderatör) #16
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 8603
Bir çözüm varmış:
mixin("
asm {
 
....
 
asıl kod
 
}");
Tabii sen makro açılımı istediğin için aşağıdaki expandNexts gibi bir işlev gerekiyor. Amaç, dizgi içindeki "Next;"leri istediğin kodla değiştirmek. Aşağıdaki ctRegex kullanan çözüm ne yazık ki derleme zamanında çalışmıyor. Onun için senin yazman gerek.

Onu yaptıktan sonra aşağıdaki writeln yerine mixin yazarsan çalışacaktır:
import std.stdio;
import std.regex;
 
string expandNexts(string input)
{
    enum e = ctRegex!("Next;", "g");
    // NOT: Tabii ki makro açılımının yerine doğru kodlar da gelmeli.
    return replace(input, e, "cmp EAX,0;");
}
 
void main()
{
    writeln (expandNexts(q{
        asm
        {
            mov EAX, 10000;
            Next;
            Next;
            Next;
            Next;
            Next;
        }
    }));
}
Bu haliyle çıktıya şunu yazdırıyor:

        asm
        {
            mov EAX, 10000;
            cmp EAX,0;
            cmp EAX,0;
            cmp EAX,0;
            cmp EAX,0;
            cmp EAX,0;
        }


Ali
Avatar
huseyin #17
Üye Haz 2012 tarihinden beri · 363 mesaj · Konum: Ankara
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Hocam bu kodun amacı nedir ?
Huseyin
Avatar
zekeriyadurmus #18
Kullanıcı başlığı: Talha Zekeriya Durmuş
Üye Eki 2012 tarihinden beri · 701 mesaj · Konum: Samsun/Türkiye
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Ali hocam cevabınızı şimdi gördüm kusura bakmayın :(

Bununla ilgili şöyle bir sıkıntı çıkar bence regex işlemi yaptığı için txt içindeki bütün Next; leri değiştirir.

Eğer kodlar arasında yorum satırı olarak veya string olarak Next; yazarsa o zaman sıkıntı çıkartır.

Veya komutNext; gibi bir kullanım olduğunda aynı şekilde sıkıntı çıkartır.

Daha iyi bir çözümü olabilir bence

Zekeriya
Bilgi meraktan gelir...
Avatar
zekeriyadurmus #19
Kullanıcı başlığı: Talha Zekeriya Durmuş
Üye Eki 2012 tarihinden beri · 701 mesaj · Konum: Samsun/Türkiye
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #17
Hocam bu kodun amacı nedir ?

Bana sormamış olsanız da cevaplayayım.

Aynı kodları en az 50 kere farklı yerlerde kullanmayı istiyoruz. Bunu fonksiyon çağırarak yapabiliriz ama bu bize hız kaybettirir. Bu projede en önemli şey hız olduğu için bunu başka bir yolla yapmaya çalışıyoruz. Bu yazılan kodlar oldukça uzun kodlar olacak isteğimiz bu uzun kodlar yerine sadece Next; yazarak derleme öncesinde Next; görülen yere o uzun kodları yerleştirilmesini sağlamak.

expandNexts fonksiyonu burada RegEx ile bu işlevi yapıyor.

Zekeriya
Bilgi meraktan gelir...
Avatar
Salih Dinçer #20
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
1 ay önceki konuyu hortlatmış gibi olsam da hız konusunda ve Talha'nın Rhodeus Script (RhS)'i ile alakalı küçük bir endişemi paylaşmak istiyorum...

Bilmiyorum diğer yorumlamalı diller böyle mi:

Biz bir takım temel işleç çarklarının (operand) assemby karşılıklarını koda yerleştiriyoruz. Sonra bunların adreslerini okuyup akıllı bir düzen içerisinde istediğimiz zaman çağrılıp iş görecek halde kullanıyoruz. Tıpkı yazılım ürettiğimiz sırada işlevleri ve değişkenleri belli yapılara (class, struct, union vb.) bölmemiz ve bunları istediğimiz zaman kurup kullanmamız gibi.

Peki call ve ret komutları ile dolu bir yorumlayıcı (öyle ya her işleç çarkı arasında gidip gelecek) ne kadar hızlı olabilir? Yani derlemeli bir dilde tüm komutlar akıllı bir şekilde ardı ardına yerleştirilirken biz RhS'de, belki de belleğin farklı bölümlerinde olan komutlara veriyi taşıp işlemelerini isteyeceğiz ve geri dönüp sırada hangi komutun olduğunu öğrendikten sonra bir sonrakine geçeceğiz...

Bunlar bana biraz, sağ elimiz ile kafamızın diğer tarafındaki sol kulağımızı tutmak kadar zor geliyor. Haksız mıyım?
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
acehreli (Moderatör) #21
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Katılıyorum. Ben RhS'in bunlara gerçekten ihtiyacı olduğuna inanmak zorundayım.

Sonuçta bu assembly örnekleriyle gerçekleştirilen kavramlar dilde de aynen var. Eğer dilin üst düzey olanakları yavaş kalıyorsa bunlar kullanılan derleyici ile de ilgili olabiliyor. Eğer assembly'de elle daha hızlı yapabiliyorsak aynı hızı derleyicinin kodları da sağlayabilir. Üstelik, dillerin üst düzey olanakları elle yapılan eniyileştirmelerden daha hızlı olabilir. Bunu C++'tan biliyoruz.

Derleyiciler inanılmaz eniyileştirmeler sunuyorlar ama dmd bu konuda gdc'den çok geride. LLVM'in çok hızlı olduğunu duyuyorum. Belki ldc de dmd'den çok daha hızlıdır.

Ali
Avatar
zekeriyadurmus #22
Kullanıcı başlığı: Talha Zekeriya Durmuş
Üye Eki 2012 tarihinden beri · 701 mesaj · Konum: Samsun/Türkiye
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
1 ay önceki konuyu hortlatmış gibi olsam da hız konusunda ve Talha'nın Rhodeus Script (RhS)'i ile alakalı küçük bir endişemi paylaşmak istiyorum...
Benim de çok endişem var :) Ama bunu zamana bırakmak daha mantıklı bence. Bu işe ilk başladığımda şimdiki gibi bir yapı yapmaya çalışsaydım yolun başında çuvallamış olur ve RhS bir hayal olarak kalırdı. Sadece son 1 ay içerisindeki ilerlemeye bakıyorum gerçekten çok yol kat etmişiz. Bu tarz şeyleri zamanla farkına varıp değiştiririz. Sonuçta şunu da gözden kaçırmamak gerek bu adamlar bunu ilk yaptıklarında mükemmel bir şey dizayn etmediler :) Zamanla onlarda hatalarını fark ettiler ve uzun bir zaman diliminde düzelttiler :) Ama tabi ki de bu tarz ayrıntıları gözden kaçırmamak gerek. Opcode olayını 0.4 yaparken farkına vardım ama opcode olayını yapabileceğimden emin değildim. 1.0 da önceki mantığı geliştirerek daha düzenli, anlaşılır ve hızlı bir kod yapısı oluşturdum ve aslında bir nevi 2.0 da yapacağım yapının temelini oluşturdum. Ve zamanla sizlerin de yardımınızla opcode olayını halletmiş olduk. Ve 2.0 ın dizaynına başladık. 2.0 da hatalarımızın farkına varırız ve 3.0 :)

Peki call ve ret komutları ile dolu bir yorumlayıcı (öyle ya her işleç çarkı arasında gidip gelecek) ne kadar hızlı olabilir? Yani derlemeli bir dilde tüm komutlar akıllı bir şekilde ardı ardına yerleştirilirken biz RhS'de, belki de belleğin farklı bölümlerinde olan komutlara veriyi taşıp işlemelerini isteyeceğiz ve geri dönüp sırada hangi komutun olduğunu öğrendikten sonra bir sonrakine geçeceğiz...
Runtime esnada asm kodu çalıştıramıyoruz. Mecburen asm kodunun bulunduğu adrese zıplayıp çalıştırabiliriz. Diğer VM'leri inceledim. Hepsi bu mantıkta çalışıyor. Salih hocam eğer dediğiniz şekilde çalışabilseydi eğer VM ler ile normal pc arasında hız farkı bulunmazdı bence.

Derleyiciler inanılmaz eniyileştirmeler sunuyorlar ama dmd bu konuda gdc'den çok geride. LLVM'in çok hızlı olduğunu duyuyorum. Belki ldc de dmd'den çok daha hızlıdır.
Belki de öyledir. C ve C++ için kesinlike öyledir diye düşünüyorum (Python kullanıyor). D için ise yorum yapamam. Sonuçta dili üreten dmd değil mi? Bundan daha iyi olacağını pek zannetmiyorum.

Bir ara C ve C++ a da geçiş yapar diğer VM leri inceleriz. Onların yapılarından da esinleniriz. Ama şu çok açık bu proje ile uğraşırken çok şey öğrendim mesela derleyici kavramıyla tanıştım. Ben sadece asp biliyordum (ona da bilmek denmez ya neyse). Interpreter dan girdim bitlerde buldum kendimi. Her ne kadar algılamada sorun yaşasam da bir şeyi algıladım mı sorun kalmıyor parçaları iyi birleştirebiliyorum( en azından şimdilik )

Not: Çok gereksiz konuştum. Kusura bakmayın :)

Zekeriya
Bilgi meraktan gelir...
acehreli (Moderatör) #23
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
zekeriyadurmus:
Sonuçta dili üreten dmd değil mi? Bundan daha iyi olacağını pek zannetmiyorum.

Dil üst düzey kavramları tanımlıyor. Bunlar derleyicilerin ön tarafı (front end) ile hallediliyor. Ön tarafın oluşturduğunu makine koduna dökmek ve eniyileştirmeler yapmak arka tarafın (back end) işi. gdc dmd'nin ön tarafını kullanıyor ama kendi arka tarafı dmd'den çok daha iyi. Bunun nedeni de arka tarafın dilden bağımsız olması ve gcc'nin C ve C++ gibi diller için zaten senelerdir çok gelişmiş olması.

Ali
Avatar
Salih Dinçer #24
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #22
zekeriyadurmus:
Interpreter dan girdim bitlerde buldum kendimi. Her ne kadar algılamada sorun yaşasam da bir şeyi algıladım mı sorun kalmıyor parçaları iyi birleştirebiliyorum( en azından şimdilik )

Not: Çok gereksiz konuştum. Kusura bakmayın :)
Estağfirullah, ne güzel demişsin bit gibi küçük bir kavramlara (ne güzel tesadüf ki dilimizde de bit çok minik bir yaratıktır!) ulaşmışsın. Bunlar öyle temel mevzular ki assembly üzerine çalışıyorsan bilmezsen olmaz derecede...:)
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
Doğrulama Kodu: VeriCode Lütfen resimde gördüğünüz doğrulama kodunu girin:
İfadeler: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Özel Karakterler:
Sayfa:  önceki  1  2 
Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-11-23, 23:23:49 (UTC -08:00)