Supporting the community

Euforia catre Translatorul C



 


1. Introducere
 
2. Compilatoarele C suportate
 
3. Cum sa pornesti translatorul
 
4. Librarii de link-uri dinamice (Librarii la comun)
 
5. Marimi executabile si compresia
 
6. Interpret vs Translator
 
7. Restrictii legale
 
9. Intrebari puse frecvent
 
10. Probleme uzuale
 
 

 

 

 

 

 

 

 

1. Introducere

 Translatorul Euphoria la C va traduce orice program Euphoria in codul sursa C echivalent.


Exista versiuni ale traducatorului pentru Windows, DOS, Linux si FreeBSD. Dupa traducerea unui program Euphoria in C, puteti sa compilati si sa va conectati utilizand unul dintre compilatoarele C suportate. Acest lucru va va oferi un fisier executabil care va rula de obicei mult mai repede decat daca ati folosit interpretul Euphoria.

Translatorul poate traduce / compila * in sine * intr-un fisier executabil pentru fiecare platforma. Traducatorul este, de asemenea, utilizat pentru traducerea / compilarea portiunii frontale a interpretului. Codul sursa pentru Traducator este in euforie \ sursa. E scris 100% in Euphoria.
2. Compilatoarele C suportate

 Translatorul functioneaza in prezent cu GNU C pe Linux sau FreeBSD, cu Watcom C sau DJGPP C pe DOS si cu Watcom C, Lcc sau Borland 5.5 pe Windows. Acestea sunt compilatoare gratuite. GNU C va exista deja in sistemul dvs. Linux sau FreeBSD. Celelalte pot fi descarcate de pe site-urile Web respective. Pentru Windows, recomandam insistent Watcom sau Borland peste Lcc. Lcc este inca in curs de dezvoltare si se imbunatateste, dar are unele bug-uri care va vor face dificila compilarea corecta a unui program Windows. Watcom si Borland sunt atat de solide. Watcom produce de obicei executabile usor mai mici, usor mai rapide, dar Borland se compileaza mult mai repede.

Pachetul Watcom DOS32 include extensia DOS CauseWay si compresorul de fisiere. CauseWay este acum open source si gratuit. Puteti afla mai multe despre asta la: http://www.devoresoftware.com

emake.bat si objfiles.lnk Se va lega automat in extensia CauseWay. Alte extensii DOS, cum ar fi DOS4GW, nu functioneaza bine cu Translatorul.

Translatorul cauta "WATCOM", "LCC", "BORLAND" sau "DJGPP" ca variabile de mediu sau directoare pe CALE. Acesta va genera un fisier emake.bat care invoca compilatorul si link-ul corespunzator.

Notite:

  • Spre deosebire de Watcom, DJGPP nu are o memorie DOS slaba in acelasi segment ca si alte memorii. Rutinele de coduri de masina scrise pentru interpretul sau translatorul  Euphoria Watcom nu vor functiona cu DJGPP si probabil ca se vor prabusi daca incearca sa acceseze memorie redusa, cum ar fi memoria video. Peek (), poke (), mem_copy (), mem_set () etc. vor functiona corect, deoarece Translatorul utilizeaza o macrocomanda speciala DJGPP pentru a accesa memoria redusa. Puteti porni aceste rutine de coduri de masina in DJGPP, dar va trebui sa consultati doc-urile DJGPP pentru posibilele modalitati de accesare a memoriei slabe.
  •  

  • DJGPP suporta pe deplin nume lungi de fisiere pentru citire, scriere si creatie. Watcom nu sustine creatia.

     

  • Traducatorul cu DJGPP nu accepta utilizarea mouse-ului.

     

  • Biblioteca grafica Allegro, pe care o folosim cu DJGPP, pare sa fie mult mai rapida decat biblioteca grafica Watcom in multe cazuri.

     

  • DJGPP accepta mai multe moduri de text, de ex. Mod de 35 linii.

     

  • DJGPP permite utilizatorului sa intrerupă un program in orice moment, tastand control-c.

     

  • Implementarea Lcc ignora lock_file () si unlock_file (). Ei nu fac nimic.

     

  • Traducatorul utilizeaza steagul de optimizare Lcc-O in emake.bat. Acest steag poate adauga uneori lipsa de fiabilitate a lui Lcc. Daca programul dvs. nu functioneaza, incercati sa eliminati acest steag din toate comenzile de compilare din emake.bat.

     

  • Avertismentele sunt dezactivate la compilarea cu emake.bat. Daca le porniti, este posibil sa vedeti cateva mesaje inofensive despre variabilele declarate, dar nefolosite, etichetele definite, dar nefolosite, prototipurile de functii care nu au fost declarate etc.

     

  • Pe Windows, link-ul Watcom ar putea emite un avertisment ca nu poate deschide graph.lib. Puteti ignora acest lucru. Graph.lib nu este utilizat. Nu pare sa existe o modalitate usoara de a suprima acest mesaj. Cea mai recenta versiune a Open Watcom pare sa fi corectat acest lucru.

     

  • Cu programele Borland si Lcc, programele de consolare Windows (text-mode) nu pot citi tastele F sau tastele sageata si este posibil sa fie nevoie sa apasati de doua ori tasta Enter. Nu exista nici o problema cu programele GUI.

     

  • Compilatorul Microsoft C ++ pentru Windows nu este inca acceptat. Totusi, puteti importa, probabil, fisierele C generate de ecw.exe si fisierul de biblioteca de executie pentru Borland, Lcc sau Watcom intr-un proiect Microsoft si compilati / conectati numai cu probleme minore.


3. Cum sa pornesti translatorul


Rularea Translatorului este similara cu rularea Interpretului. Pe DOS, tastati:

ec allsorts.ex
sau
ec allsorts

In Windows tastati:

ecw taskwire.exw
sau
ecw taskwire

In Linux/FreeBSD tastati:

ecu qsort.exu
sau
ecu qsort

dar in loc sa ruleze programul allsorts.ex, Translator va crea mai multe fisiere sursa C. Oricine poate rula Translatorul. Este inclus in euforie impreuna cu interpretul. Pentru a compila si a conecta fisierele C, trebuie sa instalati unul dintre compilatoarele C suportate. Translatorul creeaza un fisier batch numit emake.bat care face toti pasii de compilare si de legatura pentru dvs., deci nu trebuie sa stii nimic despre compilatoarele C sau C. Doar tastati:

emake

Cand compilarea si conectarea C sunt terminate, veti avea un fisier numit: allsorts.exe si fisierele sursa C vor fi eliminate pentru a evita dezordinea. Cand rulati allsorts.exe, ar trebui sa ruleze la fel ca si cand ati fi tastat: ex allsorts
Pentru al rula cu interpretul, cu exceptia faptului ca ar trebui sa ruleze mai repede, aratand timpi redusi pentru diferitii algoritmi de sortare in euforie \ demo \ allsorts.ex. Dupa crearea fisierului dvs. executabil, emake elimina toate fisierele C create. Daca doriti sa examinati aceste fisiere, rulati din nou traducatorul si examinati fisierele inainte de a rula emake. Nota pentru utilizatorii Linux si FreeBSD:

      Fisierele vor fi numite emake si shell si tastați ./emake pentru a realiza compile si link-ul, si ./shell pentru a rula programul de sortare a shell-ului.

Nota pentru utilizatorii Borland si Lcc:

      Pentru Borland si Lcc nu exista o variabil standard de mediu, astfel incat Translatorul va cauta variabila CALE in cautarea unui director probabil al compilatorului. Se afiseaza in locuri standard precum: .. \ LCC, .. \ BCC .., .. \ Borland .. etc Daca ati instalat intr-un loc nestandard, s-ar putea sa trebuiasca sa redenumiti directorul de instalare. Pentru a modifica variabila PATH pe Windows XP, faceti clic pe: Start Menu / Control Panel / Performanta si intretinere / System / Advanced / Variabile de mediu / Variabile de utilizator pentru ... Apoi selectati PATH si modificati valoarea. Introduceti undeva: C: \ BORLAND \ BCC55 \ BIN; Sau C: \ LCC \ BIN; Apoi faceti clic pe OK de cateva ori pentru a inchide ferestrele. Urmatoarea fereastra DOS pe care o deschideti ar trebui sa aiba noua valoare.

Optiuni ale Liniei de Comanda Daca se intampla sa aveti mai mult de un compilator C pentru o anumita platforma, puteti selecta pe cea pe care doriti sa o utilizati cu o optiune de linie de comanda:

      -bor
-lcc
-wat
-djg

in linia de comanda la ec sau ecw. e.g.

ecw -bor pretend.exw

In mod normal, dupa construirea fisierului .exe, fisierul batch emake va sterge toate fisierele C si fisierele obiect produse de Translator. Daca doriti ca emake sa pastreze aceste fisiere, adaugati optiunea -keep la linia de comanda a Traductorului. e.g.

ec -wat -keep sanity.ex

Sa faceti un fisier Windows .dll, sau Linux sau FreeBSD .so, doar adaugati -dll la linia de comanda. e.g.

ecw -bor -dll mylib.ew

Sa porniti o consola in Windows, adaugati la linia de comanda urmatorul lucru: -con . e.g.

ecw -bor -con myprog.exw

Pentru a mari sau a micsora cantitatea totala de spatiu rezervat pentru programul vostru, adaugati -stack nnnn la linia de comanda. e.g.

ec -stack 100000 myprog.ex

Spatiul total de stiva (in octeti) pe care il specificati va fi impartit intre toate sarcinile pe care le executati (presupunand ca aveti mai mult de unul). Fiecare sarcina are propriul spatiu privat. Daca depaseste suma alocata, veti primi un mesaj de eroare de executie care identifica sarcina si va da dimensiunea spatiului sau de stiva. Majoritatea sarcinilor non-recursive pot rula cu stive de apel cat mai mici de 2000 de octeti, dar pentru a fi siguri, ar trebui sa permiteti mai mult decât aceasta. O sarcina profund recursiva ar putea folosi mult spatiu. Totul depinde de nivelurile maxime ale apelurilor pe care o sarcina le-ar putea avea nevoie. In timpul executiei, deoarece programul dvs. creeaza mai multe sarcini simultan active, spatiul de stiva alocat fiecarei sarcini va avea tendinta sa scada.

Pentru a realiza un program DOS, compilat de WATCOM, care utilizeaza instructiuni de virgula mobila rapida, adaugati -fastfp la linia de comanda. e.g.

ec -wat -fastfp crunch.ex

In mod prestabilit, Euphoria pentru DOS solicita rutine pentru a testa daca instructiunile de virgula mobila sunt disponibile. Daca nu, atunci se folosește un cod de emulare mai lent. Cand -fastfp e specificat, codul compilat va presupune existenta unui punct plutitor hardware. Acest lucru poate cauza ca programele intensive cu puncte plutitoare sa ruleze cam de doua ori mai repede, dar nu vor reusi să functioneze deloc pe cele vechi 486 si 386 care le lipseste suportul de tip floating-point hardware. Cu -fastfp, emake.bat alege mai repede optiunile de compilare WATCOM C si emake.bat trebuie sa linkuiasca la ecfastfp.lib in loc de ec.lib.

Pe alte platfoeme, Euphoria foloseste instructiuni rapide cu virgula mobila, Iar sistemul de operare se ocupa de caz cand hardware-ul f.p. lipseste.

Pentru a va compila programul cu informatii de depanare, utilizabile cu un debugger compatibil cu compilatorul vostru, folositi optiunea -debug :

ecu -debug myapp.exu

Uneori este util sa va conectati codul tradus la o biblioteca de executie Euphoria, alta decat biblioteca furnizata implicit. Aceasta abilitate este, probabil, cea mai mare parte utila pentru testarea si depanarea bibliotecii runtime in sine sau pentru a oferi informatii suplimentare privind depanarea la depanarea codului Euphoria tradus. Retineti ca este furnizata numai biblioteca implicita. Biblioteca personalizata trebuie introdusa in directorul dvs. EUDIR / bin impreuna cu biblioteca implicita. Folositi optiunea -lib {library}:

ecu -lib decu.a myapp.exu


4. Librarii de link-uri dinamice (Librarii la comun)

Adaugand linia de comanda -dll, Translator-ul o sa faca un fisier Windows .dll (Linux/FreeBSD .so) in loc de un program executabil.

Puteti sa traduceti si sa compilati un set de rutine utile pentru Euphoria si sa le distribuiti altor persoane, fara a le oferi sursei voastre. In plus, rutinele dvs. se vor executa mult mai repede atunci cand sunt traduse si compilate. Ambele programe traduse / compilate si interpretate vor putea sa utilizeze biblioteca dvs..

Doar procedurile si functiile globale Euphoria, adica cele declarate cu cuvantul cheie "global", vor fi exportate din .dll (.so).

Orice program Euphoria, fie ca este tradus / compilat sau interpretat, poate fi legat cu un Euphoria .dll (.so) folosind acelasi mecanism care va permite sa conectati un .dll (.so) scris in C. Mai intai programul apeleaza open_dll() ca sa deschida .dll or .atunci fisierul apeleaza define_c_func() sau define_c_proc()
Pentru orice rutina pe care doreste sa o apeleze. Apeleaza aceste rutine folosind c_func() si c_proc(). Vezi library.doc pentru detalii.

Numele de rutina exportate dintr-un .dll Euphoria vor varia in funcție de compilatorul C pe care il utilizati.

GNU C pe Linux sau FreeBSD exporta numele exact asa cum apar in codul C produs de Translator, e.g. a rutina Euphoria

global procedure foo(integer x, integer y)

Ar fi exportat ca "_0foo" sau poate "_1foo" etc. Sublinierea si cifra sunt adaugate pentru a preveni conflictele de numire. Cifra se refera la fisierul Euphoria unde este definit simbolul. Fisierul principal este numerotat ca 0. Fisierele de includere sunt numerotate in ordinea in care sunt intalnite de compilator. Ar trebui sa verificati sursa C pentru a fi siguri.

Lcc o sa exporte foo() ca "__0foo@8", unde 8 este numarul de parametrii (2) inmultit cu 4. Puteti verifica fisierul facut .def de catre Translator ca sa vedeti numele exportate.

Pentru Borland Translator-ul de asemenea face un fisier .def file, dar acesta .def redenumeste simbolurile exportate inapoi in aceleasi nume pe care le-ati utilizat in sursa Euforia, deci foo() o sa fie exportat ca "foo".

Pentru Watcom are loc aceeasi redenumire cu Borland, dar in locul unui fisier .def, se adauga o comanda EXPORT objfiles.lnk pentru fiecare simbol.

Cu Borland si Watcom puteti edita .def or objfiles.lnk file, si sa rerulati emake.bat, Pentru a redenumi simbolurile exportate sau pentru a le elimina pe cele pe care nu doriti sa le exportati. Cu Lcc puteti sa inlaturati simboluri dar nu pe ele.

Avand nume frumos exportate nu este critic, deoarece numele trebuie sa apara doar o data in fiecare program Euphoria ce foloseste .dll, i.e. intr-un singur fisier define_c_func() or define_c_proc() . Creatorul unui .dll ar trebui sa furnizeze, probabil, utilizatorilor sai un fisier Euphoria care contine fisierul necesar define_c_func() si define_c_proc() el ar putea oferi chiar si un set de rutine Euphoria "wrap" pentru a apela rutinele din .dll.

Cand apelati open_dll(), Orice declaratii de nivel superior Euphoria din .dll sau .so vor fi executate precum un program normal. Aceasta ofera bibliotecii o sansa de a initializa structurile de date inainte de primul apel catre o rutina de biblioteca. Pentru multe biblioteci nu este necesara nicio initializare.

Pentru a transmite datele Euphoria (atomi si secvente) ca argumente sau pentru a primi un obiect Euphoria ca rezultat, va trebui sa utilizati urmatoarele constante in euphoria\include\dll.e:

      -- Tipuri de Euphoria pentru .dll (.so) argumente si valori returnate:

      constanta globala

		      E_INTEGER = #06000004,

		      E_ATOM    = #07000004,

		      E_SEQUENCE= #08000004,

		      E_OBJECT  = #09000004

 

Folosit astea in define_c_proc() si define_c_func() ca si cum ati folosi C_INT, C_UINT etc. sa apelati C .dll's si .so's.

In prezent, numerele intoarse de la open(), si IDurile de rutina routine_id(), Pot fi transmise si returnate, dar biblioteca si programul principal au fiecare propria lor idee separata despre ceea ce inseamna aceste numere. In loc sa treceti numarul fisierului unui fisier deschis, puteti sa treceti numele fisierului si sa il deschideti .dll (.so). Din pacate, nu exista o solutie simpla pentru trecerea id-urilor de rutina. Aceasta ar putea fi rezolvata in viitor.

Un .dll Euphoria sau .so In prezent, nu pot executa operatiuni de multitasking. Translatorul va va oferi un mesaj de eroare despre acest lucru.

Datele de euforie (.so) pot fi, de asemenea, utilizate de catre programele C, atata timp cat se schimba numai valori intregi de 31 de biti. Daca un indicator sau un numar pe 32 de biti trebuie sa fie transmis si aveti sursa programului C, puteti trece valoarea in doua argumente individuale de 16 biti separate (16 biti superior si 16 biti inferiori) si apoi combinati valorile in rutina Euphoria in atomul dorit de 32 de biti.
5. Marimi executabile si compresia

Cu DOS32 cu Watcom, daca Translator-ul gaseste fisierele cwc.exe si le23p.exe in euphoria\bin, o sa adauge comenzi la emake.bat care vor arhiva executabilul. Daca nu doriti compresie, puteti edita emake.bat, sau sa eliminati sau sa redenumiti cwc.exe si/sau le23p.exe.

In Linux, FreeBSD, Windows, si DOS32 cu DJGPP, emake nu include linie de comanda ca sa comprime fisierul. Daca vrei asta incercati compresorul gratis UPX. Il puteti obtine de la: http://upx.sourceforge.net Large Win32Lib-based .exe's si oate compresa pana la 15% din marimea originala, si nu veti observa diferente in timpii de pornire.

Translatorul sterge rutinele care nu sunt utilizate, inclusiv cele din fisierele standard Euphoria incluse. Dupa stergerea rutinelor neutilizate, acesta verifica din nou mai multe rutine care au devenit neutilizate si aaa mai departe. Acest lucru poate face o mare diferenta, mai ales in cazul programelor bazate pe Win32Lib in care este inclus un fisier mare, dar multe dintre rutinele incluse nu sunt utilizate intr-un anumit program.

Cu toate acestea, fisierul dvs. executabil compilat va fi probabil mai mare decat acelasi program Euphoria legat de back-end-ul interpretului. Acest lucru se datoreaza in parte faptului ca back-end-ul este un executabil comprimat. De asemenea, afirmatiile Euphoria sunt extrem de compacte atunci cand sunt stocate intr-un fisier legat. Ei au nevoie de mai mult spatiu dupa ce au fost traduse in C si compilati in codul masina. Viitoarele versiuni ale Translatorului vor produce executabile mai rapide si mai mici.
6. Interpret vs Translator

Toate programele Euphoria pot fi traduse in C si, cu doar cateva exceptii de mai jos, se vor executa la fel ca in cazul Interpret-ului (dar mai arepede).

Interpret-ul si Translator-ul impart acelasi parser, astfel incat o sa obtineti aceleasi erori de sintaxa, variabile care nu au fost declarate erori etc. cu oricare dintre acestea.

Interpret-ul in mod automat extinde stiva apelurilor (pană cand memoria este epuizata), astfel incat sa puteti avea un numar mare de nivele de apeluri imbricate. Majoritatea compilatoarelor C, in majoritatea sistemelor, au o limita prestabilita pentru marimea stivei. Consultati manualul dvs. de compilator sau linker daca doriti sa mariti limita, de exemplu daca aveti o rutina recursiva care poate necesita mii de niveluri de recurenta. Modificati comanda de conectare in emake.bat. Pentru Watcom C, utilizati OPTION STACK = nnnn, unde nnnn este numarul de octeti din spatiul de stiva.

Nota:

      Translator-ul presupune ca programul dvs. nu are erori de executie in el care ar fi prins de catre Interpreter. Translator-ul nu verifica pentru: subscript nedefinit, variabile neinitializate, Atribuind un tip de date gresite unei variabile, etc.

Ar trebui sa va depanati programul la Interpret. Traducatorul verifica anumite erori de executie, dar in interesul vitezei, majoritatea nu sunt verificate. Cand se trag codurile C, veti primi de obicei o exceptie de masina foarte criptica. In majoritatea cazurilor, primul lucru pe care ar trebui sa-l faceti este sa rulati programul cu Interpretorul, utilizand aceleasi intrari si, de preferinta, cu type_check pornit. Daca eroarea apare doar in codul tradus, puteti utiliza cu urmarirea si urmarirea (3) pentru a obtine un fisier ctrace.out care prezinta un buffer circular al ultimelor 500 de declaratii Euphoria executate. Daca este afisat un mesaj de eroare detectat de traducator (si stocat in ex.err), veti vedea, de asemenea, linia infractionala a sursei Euphoria ori de cate ori este activa. Cu urmari va incetini programul dvs. si incetinirea poate fi extrema atunci cand trace (3) este, de asemenea, in vigoare.
7. Restrictii Legale

In ceea ce priveste RDS, toate programele executabile sau .dll-urile pe care le creati cu acest Translator fara a modifica un fisier de biblioteca de traduceri RDS, pot fi distribuite gratuit. Sunteti liber sa includeti fisierele Euphoria furnizate de RDS in aplicatia dvs..

In ianuarie 2000, extenderul CauseWay DOS a fost donat domeniului public de Michael Devore. El si-a predat drepturile de autor si incurajeaza pe oricine sa o foloseasca liber, inclusiv pentru uz comercial.

In general, daca doriti sa utilizati codul Euphoria scris de terte parti, ati fi onorat mai bine toate restrictiile care se aplica. Daca aveti indoieli, trebuie sa cereti permisiunea.

Pe Linux, FreeBSD si DJGPP pentru DOS32, licenta GNU Library nu va afecta in mod normal programele create cu acest Translator Simpla compilare cu GNU C nu ofera Fundatiei Free Software nicio jurisdictie asupra programului tau. Daca le conectati in mod static la biblioteci, vi se va aplica licenta lor de biblioteca, dar procedeul standard de compilare / legătura in emake nu leaga in mod static orice biblioteci FSF, deci nu ar trebui sa existe nici o problema.

Biblioteca grafica Allegro, folosita de DJGPP, este mentionată in documentatie ca "Giftware" si va permite sa o redistribuiti ca parte a programului dvs. Ei cer, dar nu necesita, o recunoastere.

Negare:

      Aceasta este ceea ce credem ca este situatia. Nu suntem avocati. Daca este important pentru dvs., ar trebui sa cititi licenta GNU Library, comentariile legale din DJGPP, Lcc si Borland si fisierul read.me al lui Michael Devore de pe site-ul sau, pentru a va forma propria judecata.



9. Intrebari puse frecvent

Q - Cat de mare accelerare ar trebui sa ma astept?
A - Totul depinde de programul pe care-l petrece si timpul. Programele care utilizeaza in principal calcule intregi, nu numesc rutine de executie foarte des si nu fac prea multe I / O va vedea cea mai mare imbunatatire, in prezent pana la aproximativ 5 ori mai rapid. Alte programe pot vedea doar cateva imbunatatiri la suta. Diferitele compilatoare C nu sunt egale in capacitatea de optimizare. Watcom, GNU C si DJGPP produc cel mai rapid cod. Borland este destul de bun. Lcc se situeaza putin in spatele celorlalte, chiar si atunci cand este folosit steagul -O. Borland compileaza cel mai rapid. Watcom compileaza cel mai incet.
Q - Ce se intampla daca vreau sa schimb optiunile de compilare sau de legatura in emake.bat?
A - Simtiti-va liber sa faceti acest lucru, totusi ar trebui sa copiati emake.bat in propriul fisier numit (say) mymake.bat, apoi rulati mymake.bat dupa rularea Translator. Ocazional, numarul de fisiere .c produse de Traducator s-ar putea schimba.
Q - Cum pot face programul meu sa functioneze si mai repede?
A - Este important sa se declare variabilele ca intreg atunci cand este posibil. In general, ajuta la alegerea tipului cel mai restrictiv posibil la declararea unei variabile. Tipurile tipice definite de utilizator nu va vor incetini. Deoarece programul dvs. ar trebui sa nu contina erori de tipul type_check, tipurile sunt ignorate de catre Traducator, cu excepția cazului in care le apelati direct cu apeluri functionale normale. Singura exceptie este atunci cand o rutina de tip definita de utilizator are efecte secundare (adica seteaza o variabilă globala, efectueaza procesari in memorie, I / O etc.). In acest caz, daca cu type_check este in vigoare, Translator-ul va emite un cod pentru a apela rutina de tip si va raporta orice esec tip_check care rezulta. Pe sistemele Windows si DOS am lasat optimizarea pentru bucla / ol pentru wcc386 de la Watcom. Am gasit in cateva cazuri rare ca aceasta optiune a condus la codul masinii incorect emis de compilatorul Watcom C. Daca il adăugati in versiunea proprie de emake.bat, puteti obtine o usoara imbunatatire a vitezei, cu un risc mic de cod bug-uri. Pentru DJGPP este posibil sa incercati -O6 în loc de -O2. Pentru DOS folosim optiunea Watcom / fpc care genereaza apeluri in rutine de executie pentru a efectua operatiuni in virgula mobila. Daca aparatul are hardware cu punct de plutire, acesta va fi utilizat de rutina, altfel va fi folosita emulatia software-ului. Acest lucru incetinește intr-o oarecare masura si nu este necesar pe Pentium, dar garanteaza ca programul dvs. va funcționa pe toate masinile 386 si 486, chiar daca acestea nu au hardware de tip punct plutitor. Biblioteca DOS run-time, ec.lib, a fost construita in acest fel, astfel incat sa nu puteti elimina pur si simplu aceasta optiune. Pe Linux sau FreeBSD puteti incerca optiunea O3 de gcc in loc de O2. Acesta va "in-line" mici rutine, imbunatatind viteza usor, dar crearea unui executabil mai mare. Puteti incerca, de asemenea, Intel C ++ Compiler pentru Linux. Este compatibil cu GNU C, dar ar putea fi necesare unele ajustari pentru a emite.


10. Probleme uzuale

Multe programe mari au fost traduse cu succes si compilate folosind fiecare dintre compilatoarele C suportate, iar Traducatorul este acum destul de stabil.

Nota:

      In Windows, daca apelati o rutina C care utilizeaza conventia de apelare cdecl (in loc de stdcall), trebuie sa specificati un caracter "+" la inceputul numelui rutinei in define_c_proc () si define_c_func (). Daca nu, apelul poate functiona la rularea exw Interpreterului, dar probabil va esua (crash) atunci cand traduceti si compilati cu Borland sau Lcc.

In unele cazuri, o rutina enorma de Euphoria este tradusa in C, si se dovedeste a fi prea mare pentru compilatorul C sa proceseze. Daca intampinati aceasta problema, faceti rutina dvs. Euphoria mai mica si mai simpla. De asemenea, puteti incerca sa opriti optimizarea C in emake.bat doar pentru fisierul .c care nu reuseste. Spargerea unei singure declaratii constante a mai multor variabile in declaratii constante separate ale unei singure variabile fiecare, poate, de asemenea, sa ajute. Euforia nu are nici o limita in ceea ce priveste dimensiunea unei rutine sau dimensiunea unui fisier, dar majoritatea compilatoarelor C o fac. Traducatorul va produce automat mai multe fisiere mici .c dintr-un fisier Euphoria mare pentru a evita accentuarea compilatorului C. Cu toate acestea, nu va rupe o rutina mare in rutine mai mici.

Postati erori pe EUforum.
In special, raportati orice program care nu ruleaza la fel atunci cand este compilat ca atunci cand este interpretat.

Translated by: Irina Vasilescu

Link to the original page: Click Here

We love giving back to the community

We believe in helping people and that matter to us more than anything else. Since the very beginning of our company, our team have been willing and wishing to help.