կոմպիլեատոր

• 2022-12-11-16203887 – 2022-12-11
  

  անդրէ շտալցը շատ հետաքրքիր գրառում ա արել (նոր չի արել, ես եմ նոր կարդացել) այն մասին, ինչպէս էր փորձում իր js֊ով գրուած secure scuttlebutt֊ի յաւելուածի՝ manyverse֊ի, կոդի հատուածները թարգմանել rust֊ի։

  ահա՝ https://staltz.com/rust-for-mobile-not-yet.html

  հիմնականում լաւ նորութիւններն էին՝

  • թարգմանութիւնը js֊ից rust բարդ չէր, ահագին հեշտ թարգմանւում էր։
  • շահել ա որոշ չափով արագութիւն՝ 10%-25%։

  չնայած նա գոհ էր, եւ աւելի շատ էի սպասում։

  ինչը չի չափել, ու ինչն ինձ հետաքրքիր ա՝ օպերատիւ յիշողութեան օգտագործումը։ ինձ թւում ա՝ պիտի շաաատ աւելի քիչ լինէր։

  իսկ վատ նորութիւնները, ինչի համար էլ հետարկեց իր փոփոխութիւնները՝

  • շինելու երկար ժամանակ։

  ասում ա՝ 3 րոպէ էր rust քոմփայլերին պահանջւում մի պարզ գրադարան շինելու համար։

  իսկ ամէն գրադարանը պէտք ա հաւաքէր մի քանի պրոցեսորի համար։ ու պարզւում ա որ պէտք ա երկար սպասել, որ ստանաս ու փորձարկես արդիւնքը։ սա յայտնի խնդիր ա, ու կան լուծումներ՝ տեսականօրէն rust֊ը կարողանում ա «քեշ» անել շինելու արդիւնքները, բայց շտալցին չյաջողուեց այդ «քեշաւորումն» օգտագործել մոբայլ գործիքների հետ՝ nodejs-mobile, Android Gradle, ու դէ XCode֊ի։

  • ստացուած բինարների չափսը

  ասում ա՝ մեծ էր։ ասում ա, ստացւում էր, որ 100մբ֊ից մեծ apk ա լինելու manyverse֊ի մօտ, եթէ ամէնը rust֊ի թարգմանեմ։

  էստեղ ես չգիտեմ։ մի կողմից՝ 100մբ֊ն, հա, շատ ա։ ու էդ ամէնը օպերատիւ յիշողութեան մէջ ա լինելու։ միւս կողմից՝ js կոդը չնայած փոքր ա աւելի՝ դէ տեքստ ա, բայց եւ ինտերպրետացիան անհամեմատ, իթ, աւելի շատ օպերատիւ յիշողութիւն ա պահանջելու։

  էստեղ կարելի ա ասել, որ երեւի թէ, եթէ rust չլինէր, այլ կներէք, «նորմալ» նատիւ կոդ գեներացնող լեզու, ամէն դէպքում էդքան մեծ կոդ չէր գեներացնի։ ու էդ խնդիրը չէր զգայ։

  նաեւ, երկար չէր տեւի դա։

  պլիւս դրան իր մօտ ստացւում էր, որ ամէն իր ռասթ մոդուլը պէտք ա ունենար նոյն կախուածութիւնները՝ «base64, byteorder, cfg-if, libc, memchr, rand, serde, thread_local» ու իր մօտ չէր ստացւում որ դրանք մէկ անգամ լինեն, այլ ոչ ամէն ռասթ մոդուլի համար։

  ասում ա՝ գուցէ հնարաւոր ա որպէս դինամիկ գրադարան դրանք աւելացնել, բայց էլի՝ գաղափար չունեմ ինչպէս։

  էստեղ կասեմ՝ գուցէ էլի ռասթից ա, որ յարմար միջոցներ չի տալիս դրա համար։

  օրինակ, չնայած ես դա չեմ սիրում, բայց պասկալում շաաաատ հեշտացուած ա կրոսպլատֆորմ գրադարաններ գեներացնելը՝ մոդուլի վերնագիրը դնում ես ոչ թէ unit այլ library եւ քոմփայլերը գեներացնում ա քեզ so, dll կամ dylib։

  էստեղ էլ այլ խնդիր՝ apple֊ի հետ կապուած, իրենք sdk֊ից հանել են բոլոր dylib֊երը, ու փոխարինել tbd֊ներով։

  եւ շաատ կարեւոր պահ՝ իր rust֊ով գեներացուած բինարները չեն աշխատում՝ պայթում են android 5֊ի տակ։ իսկ ի պատիւ իրան, նա մտածում ա այն մասին, որ հին անդրոիդների վրայ իր յաւելուածն աշխատի՝ զի մտահոգուած ա մեանմայի օգտատէրերի մասին։ իսկ իրենց զգալի մասը՝ անդրոիդ հինգի վրայ են։

  բնօրինակն ունէք, թէ էլի մանրամասներ են հետաքրքրում։

  ընդհանուր առմամբ, ինձ թւում ա, ռասթի մոլորեցնող հմայքը ստիպեց անդրէին այն փորձել, եւ հիասթափուել։ բայց եթէ նա նոյնը փորձէր անել ոչ էդքան մարկէտ արուած լեզուով, բայց նատիւ կոդ գեներացնող լեզուով՝ շատ հաւանական ա, աւելի լաւ արդիւնք ունենար։

  ի դէպ, հէնց հիմա ռասթ ա շինում մեքենաս։ գիշերը թարմացումը չեղաւ, զի 13գբ տեղ չմնաց այն շինելու համար։ իսկ փայնբուքի վրայ լաւ զգում եմ՝ թէ ուզում եմ ֆայրֆոքս, պիտի շինեմ նաեւ ռասթ, իսկ այ դա տեւում ա աւելի երկար, քան ֆայրֆոքս շինելը՝ մի երկու֊երեք օր։

  եւ այդպէս։

  #անդրոիդ #այօս #սքաթլբաթ #յաւելուած #ծրագրաւորում #կազմարկիչ #կոմպիլեատոր #քոմփայլեր #ռասթ #ջս #մենիվերս #էփլ #պատմութիւն

  բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)

  անդրոիդ այօս սքաթլբաթ յաւելուած ծրագրաւորում կազմարկիչ կոմպիլեատոր քոմփայլեր ռասթ ջս մենիվերս էփլ պատմութիւն
• 2020-09-02-4499474 – 2020-09-02
  

  հաւէս յօդուած ա սա շատ՝ https://www.joelonsoftware.com/2001/12/11/back-to-basics/

  իսկ օբերոնում վիրտը որոշել ա հրաժարուել պասկալական տողերից, ու կիրառել զրօյով աւարտուող տողեր։

  սակայն, էդ տողերով կարիք չկայ միշտ վազել չափն իմանալու համար։ առանձին դաշտ էլ պէտք չի օգտագործել ու յիշողութեան մէջ մի տեղ պահել չափսը՝ քոմփայլերը գիտի տողի երկարութիւնը։

  ու քոմփայլ թայմ թեստ կարող ա անել։ դիցուք վերցնենք էս ելատեքստը՝

  MODULE tst;
  IMPORT Out;
  
  VAR i: SHORTINT;
  str: ARRAY 1024 OF CHAR;
  
  BEGIN
  
  FOR i := 0 TO LEN(str) DO
  Out.Int(i, 0); Out.Ln
  END;
  
  END tst.
  

  այն քոմփայլ չի լինի՝

  [2020-09-02 16:00:20] $ voc -m tst.Mod 
  tst.Mod  Compiling tst.
  
  9:   FOR i := 0 TO LEN(str) DO
  ^
  pos   102  err 113  incompatible assignment
  
  Module compilation failed.
  [2020-09-02 16:00:21] $
  

  voc֊ը որ դէպի C ա թարգմանում սորսը, շատ լաւ ա պատկերելու համար։ եթէ մենք ունենք՝

  str: ARRAY 16 OF CHAR;
  

  ապա ելքային C կոդը կը լինի՝

  static CHAR tst_str[16];
  

  միայն դա։

  իսկ

  FOR i := 0 TO LEN(str) DO
  

  կը թարգմանուի որպէս՝

  tst_i = 0;
  while (tst_i <= 16) {
  

  Երբ մենք գրում ենք տողի հետ աշխատող ֆունկցիա, մենք կարող ենք չիմանալ փոխանցուող տողի երկարութիւնը՝

  MODULE tst2;
  
  PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
  BEGIN
  (* do smth useful here *)
  END addStrs;
  
  PROCEDURE test*;
  VAR
  s0: ARRAY 32 OF CHAR;
  s1: ARRAY 64 OF CHAR;
  BEGIN
  addStrs(s0, s1);
  END test;
  
  END tst2.
  

  եւ ապա սի կոդը կը լինի՝

  static void tst2_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
  {
  /* here we think we can do smth useful */
  }
  
  void tst2_test (void)
  {
  CHAR s0[32];
  CHAR s1[64];
  tst2_addStrs((void*)s0, 32, (void*)s1, 64);
  }
  

  այսինքն՝ ֆունկցիան ստանում ա նաեւ տողի երկարութիւնը։ ու եթէ անել LEN(a) անմիջապէս՝ առանց ոչ մի հաշուարկ՝ ստանում ես տողի երկարութիւնը։

  ապա ինչպէ՞ս են աշխատում դինամիկ տողերը։

  MODULE tst3;
  
  PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
  BEGIN
  (* do smth useful here *)
  END addStrs;
  
  PROCEDURE test*(i: INTEGER);
  VAR
  s: ARRAY 32 OF CHAR;
  ps: POINTER TO ARRAY OF CHAR;
  BEGIN
  NEW(ps, i);
  addStrs(s, ps^);
  END test;
  
  END tst3.
  

  ունենք մի հատ ստատիկ տող՝ s ու մի հատ դինամիկ տողի ցուցիչ՝ ps։ ps֊ի չափսը կը ստանանք որպէս ֆունկցիայի արգումենտ՝ էս պահին մեզ անյայտ ա։

  առաջին ֆունկցիան մնում ա անփոփոխ, երկրորդը թարգմանւում ա սէնց՝

  static void tst3_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
  {
  /* do smth useful here */
  }
  
  void tst3_test (INT16 i)
  {
  CHAR s[32];
  struct {
  ADDRESS len[1];
  CHAR data[1];
  } *ps = NIL;
  ps = __NEWARR(NIL, 1, 1, 1, 1, ((ADDRESS)(i)));
  tst3_addStrs((void*)s, 32, (void*)ps->data, ps->len[0]);
  }
  

  _NEWARR֊ն արդէն մի քիչ բարդ ֆունկցիա ա, որը ռանթայմի մաս ա։ բայց ընդհանուր առմամբ պարզ ա ինչ ա անում՝ հիփ֊ի մէջ ալոքէյթ ա անելու տող, եւ մեր ստացած ցուցիչն արդէն struct֊ի ա, որն ունի data դաշտ եւ len դաշտ։

  սա ռանթայմ տեղեկատւութիւն ա, ու այս դէպքում արդէն մեզ պէտք ա պահել առանձին դաշտ տողի երկարութեան համար։

  ու տէնց։

  #օբերոն #ծրագրաւորում #տող #տողեր #պասկալ #սի #վիշապ #իրականացում #կազմարկում #կոմպիլյատոր #կոմպիլեատոր #կազմարկիչ

  բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

  օբերոն ծրագրաւորում տող տողեր պասկալ սի վիշապ իրականացում կազմարկում կոմպիլյատոր կոմպիլեատոր կազմարկիչ