մատեան անկապութեան

կազմարկիչ

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

եւ այդպէս։

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

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
անդրոիդ այօս սքաթլբաթ յաւելուած ծրագրաւորում կազմարկիչ կոմպիլեատոր քոմփայլեր ռասթ ջս մենիվերս էփլ պատմութիւն
2021-09-28-6056330 – 2021-09-28

պարզւում ա, հնարաւոր չի էփլի ափսթոր լցնել որեւէ բան, որը շինած ա gcc֊ով, կամ դրա վրայ հիմնուած կազմարկիչով։

այդ պատճառով, օրինակ, չի կարելի ադայով գրուած յաւելուած վերբեռնել՝ ադա կազմարկիչն այս պահին հիմնուած ա ջիսիսիի վրայ։

էփլը տարօրինակ պահանջներ ունի, զի ջիսիսի֊ով կարելի ա շինել նաեւ սեփականատիրական ծրագրակազմ։

ու ես հասկանում եմ որ էփլը վաղուց պատկերացնում էր ինչ տեսակի սահմանափակումներ են ուզում ունենալ, այդ պատճառով էլ ֆինանսաւորում էր llvm նախագիծը՝ որը կը լինի ֆորմալ ազատ, բայց իրենց պահանջներին կը բաւարարի։

նախ, պէտք չի էփլի բարութեան մասին պատրանքներ ունենալ՝ llvm֊ը բնաւ էլ էփլի նուէրը չէր համայնքին, այլ ստեղծուած իրավիճակում, երբ ազատ ծրագրակազմի շարժումն արդէն ուժեղ էր ու նախագծողները սովոր են ազատ գործիքների, եւ gcc֊ին բաւական զարգացած էր ու վաղուց ունէր բազմաթիւ ֆրոնտէնդներ, էփլին պէտք էր կարողանալ առաջարկել նախագծողներին ընդունելի այլընտրանք։

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

երրորդը՝ ես չեմ կարող գրել այօսի համար շատ լաւ ու շատ տարբեր ազատ գործիքներով՝ զի ֆաշիստ են։

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

եւս մի պատճառ էփլը չսիրելու, ու bsd արտօնագրերը չսիրելու։

բաւական տհաճ էր նաեւ պատմութիւնը, երբ vlc նուագարկիչը չէր կարելի աւելացնել գուգլի «փլէյ սթոր»՝ զի ըստ gpl արտօնագրի չի լինի մարդուց խլել ստացած ծրագիրը տարածելու ազատութիւնը։ իսկ գուգլը ուզում էր չթողնել ներբեռնուած յաւելուածը նոյնիսկ պահել մօտդ, կամ այլ սարքի մէջ տեղակայել։ վճարե՛լ ես ծրագրի համար, ոնց որ քո՛նն ա, բայց մէկ ա պիտի կախուած լինես գուգլից։

նոյնիսկ ազա՛տ ա ծրագիրը՝ vlc֊ն ա, որ հազար տարի գիտենք՝ բայց պարզւում ա այն պէտք ա դարձնել անազատ՝ խանութում ձրի ներբեռնելու հնարաւորութեամբ տեղաւորելու համար։

ու նուագարկիչի թիմը ստիպուած եղաւ կապուել նախագծին աջակցած բոլոր֊բոլոր կոդի քոմիթերների հետ եւ համոզել ռելայսնսել կոդը bsd արտօնագրով։

եւ ո՞նց են դրանից յետոյ ասում, որ bsd֊ն աւելի ազատ արտօնագիր ա՝ դրա օգնութեամբ մարդկանց զրկեցին ձեռք բերուած եւ ազատ ծրագիրը տարածելու իրաւունքից, ազատութիւնից, պարտադրելով խոշոր ընկերութիւնից կախուածութիւն, ու փաստացի մենք ունենք իրավիճակ, երբ bsd արտօնագիրը սատարում ա մենաշնորհներին։

#ադա #ծրագրաւորում #կազմարկում #կազմարկիչ #արտօնագիր #մենաշնորհ #էկրանահան #էփլ #ֆաշիստներ #գուգլ #ազատութիւն

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
ադա ծրագրաւորում կազմարկում կազմարկիչ արտօնագիր մենաշնորհ էկրանահան էփլ ֆաշիստներ գուգլ ազատութիւն
2021-08-25-5414561 – 2021-08-25

պասկալ կոմպիլեատորի մասին գիրք՝

https://homepages.cwi.nl/~steven/pascal/book/pascalimplementation.html

#գիրք #պ4 #պասկալ #կոմպիլգատոր #կազմարկիչ #ծրագրաւորում #տեք

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
գիրք պ4 պասկալ կոմպիլգատոր կազմարկիչ ծրագրաւորում տեք
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 դաշտ։

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

ու տէնց։

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

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
օբերոն ծրագրաւորում տող տողեր պասկալ սի վիշապ իրականացում կազմարկում կոմպիլյատոր կոմպիլեատոր կազմարկիչ
2019-10-10-3857943 – 2019-10-10

https://sourceforge.net/p/predef/wiki/Compilers/ այստեղ հաւաքած ա, թէ որ կազմարկիչը ինչպէս ա դիֆայն լինում, որ լինի պարզել թէ որ կազմարկիչով ես հաւաքում իֆդեֆ անելով։

#վիքի #կազմարկիչ #ծրագրաւորում

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
վիքի կազմարկիչ ծրագրաւորում