Results 1 to 1 of 1

Thread: FPC Developer nieuws

  1. #1
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357

    FPC Developer nieuws

    Nieuws

    • Begin deze week is Lazarus 0.9.26 afgebranched, en voor enkele platforms reeds gebouwd. Ik had 'm eigenlijk al afgelopen week verwacht, maar neem aan dat dat nu volgende week wordt (nog een weekendje erbij)
    • In Lazarus-Trunk is de default widget set op "GTK2" gezet, vroeger dan geplanned (origineel voor 1.2), omdat steeds meer Linux distributies zwaar unicode gebruiken. 0.9.28 zal dus default GTK2 zijn ipv GTK1
    • Hopelijk krijgt FPC 2.2.2 komende week een pull up naar Ubuntu. Mijn god, wat is deze distributie traag. (2.2.2 is van augustus, en de release bevatte Debian .debs)
    • Jonas meldt eerste successen bij devirtualizatie. (in een aparte branch maar binnenkort misschien in -trunk) Deze globale optimizalisatie maakt een methode automatisch statisch ipv virtueel indien deze niet virtueel gebruikt wordt. (zie verder beneden)
    • Zelf ben ik op dit moment niet veel met FPC bezig. Alleen een beetje aan het spelen met de interne CHM compiler (OS+architectuur onafhankelijk) en bijbehorende tools en documentatie systemen. Met name een poging aan het doen de textmode IDE op elk platform CHM te laten lezen, dit begint reeds langzaam te werken Tevens vergt het debuggen van de nieuwe FreeBSD/x86_64 port ook tijd.
    • een van de redenen voor devirtualizatie is dat Jonas denk aan een llvm backend, en LLVM heeft deze info nodig om efficient te kunnen werken. Het schijnt dat Apple met zijn 4 actieve architecture (PPC + x86 en twee 64-bits varianten) hier zwaar op in zet.


    Devirtualizatie

    De devirtualizatie optimalizatie levert an sich niet zo veel op (denk 50k op een 2MB binary), maar het moet met name de combinatie van de gewone optimalizaties (en met name het feit dat een methode dan inlinebaar is) zijn die de winst op levert.

    Er zijn verder ook een hoop praktische problemen, b.v. een

    Code:
    obj.classtype.create;  // met obj:TObject;
    kan in theorie elke classe creeeren, wat de gegevens verzameling voor devirtualizatie verstoord. Streaming code kan verder ook ieder (geregistreerd) type creeeren, hetgeen een ongebruikt unitje met componenten includen wel heel duur maakt.

    Voorlopig ga ik er meer vanuit dat dit nog lange tijd niet voor LCL/VCL designtime gebaseerde code gaat gelden, en zelfs indien, dan nog onder voorwaarden.
    Last edited by marcov; 12-Oct-08 at 14:31.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •