C - alocarea memoriei + alte chestiuni

Buna seara. Am cateva lacune ... Desi invat in particular si am cartile recomandate de voi (scrise de BJarne S.) doresc sa intru mai in detaliu. Cateva intrebari pe care le-am notat si la care cer ajutor:
1. Cum se aloca efectiv memoria ? De ex. am codul sursa:

#include <iostream>
using namespace std;
int main(){
int v;
string s;
return 0;
}

Cine poate sa-mi explice exact ce se intampla din momentul in care se compileaza codul? Pas cu pas pana la nivel hardware (chiar si la nivel de registru/RAM/tranzistori), tot ce se intampla ,,in spate", din momentul compilarii.
Cum se aloca sizeof(int) din RAM? Random ? Pe ce principiu se alege dintre toate adresele libere - cum se detecteaza o adresa ,,libera,, -, byteul de la care incepe variabila v? Fiind vorba de compilare si nu de interpretare (rand cu rand), exista un principiu in ceea ce priveste alocarea memoriei pt. toate variabilele din program?

2. Codul scris este pe hard (memorie nevolatila). In momentul compilarii si executarii se aduce tot ,,textul" in RAM unde se compileaza si se executa? Practic care este limbajul tinta al unui compilator (ma refer la lexicul limbajului tinta) ? Care ar fi firul (lexical) pornind de la limbajul C efectiv, pana la codul masina ? Un exemplu va rog (pe un cod de 3-4 randuri) ?

3. O functie cum este salvata in memorie? Este salvat ,,textul" (definirea functiei) sau doar ceea ce face? O sa iau un exemplu (chiar daca exista deja operatorul ++):

void increase(int& var){
var=var++;
}

La compilare, se creaza in RAM un fel de:

in A;
add A, 1;

iar cand avem un apel de ex. increase(valoare) se face - MOV A, &valoare - si se executa rutina de mai sus?

4. Daca avem de ex. o clasa neinstantiata (sau orice altceva, variabile globale de ex.), iar in main nu avem nimic (nu se executa nimic), totusi la compilare se fac ceva salvari in RAM (scheletul clasei este salvat)? Sau atata timp cat in main() nu se aduce vorba de tipul T, nici nu stie ca exista / nu e salvat?

#include ...
class T{
private:
int a, b;
public
T() : a(0), b(0){};
};
int main(){
return 0;
}

Nicaieri (nici macar creatorul C) nu mentioneaza si chestiuni din ,,spatele" limbajelor, ci doar cum se folosesc si ce fac. Nici macar o corelare cu limbajul de asamblare (ca sa urmarim pas cu pas ce se face in spate).

Edited by AndreiCCC, 14 September 2016 - 20:52.

Atunci cand scrii cod C/C++, tu spui la un nivel mai inalt calculatorului ce sa faca, dar nu si cum. Tranzlatia dintre ce si cum este lasata in seama compilatorului (oarecum). Fiecare compilator are liber sa faca cum crede de cuviinta. Mai mult, exista diferente majore dintre o compilare cu debug si una fara. Nici nu vreau sa amintesc faptul ca depinde de arhitectura procesorului din spate.
Si nici compilatorul nu are acces la cel mai de jos nivel, unde mai pot fi alte abstractizari (e.g.: S.O.-->paging, CPU-->cache level x, ...).

Daca vrei sa discuti despre o anumita arhitectura (e.g. x86 sau amd64), atunci lucrurile devin mai concrete, insa inca o data, depinde mult si de sistemul de operare.

Ce vrei tu nu inveti intr-o carte de C/C++ Incerca sa gasesti niste carti vechi the programare Win32 API sau chiar MFC - inclusiv in format electronic pe internet O buna referinta ar fi Windows Internals dar nu o vei intelege la nivelul tau Poate peste 10 ani , daca te tii de treaba

Ce doresti sa afli se invata in mai multe discipline, e cam greu sa le rezumi in cateva randuri. Chiar daca in final ca programator retii putin, intelegi pe deplin cum sa scrii cod de nivel inalt asa incat sa profiti de abilitatile low-level ale unui calculator.
E vorba de arhitectura calculatoarelor, teoria limbajelor de programare, etc.

Cauta , de exemplu, Programming Windows, 5th Edition de Charles Petzold

Sau carti de Jeffrey Richter

Am o oarecare ,,experienta" (in niciun caz ca a voastra, de aceea am apelat la voi), dar totul a fost/este mecanic. Nu mecanic in sensul de tocit, ci in sensul ca nu stiu ce se intampla in spate. Stiu ca aloc memorie, dar nu stiu cum PC-ul a ales fix adresa 0xBBCCDDAA pt. variabila cutare. Sau cum s-a ajuns la codul masina 023232....

Si la liceu era replica simpla: se aloca memorie. Apoi ghicesti tu cum, de ce, de unde ....

Edited by AndreiCCC, 14 September 2016 - 21:46.

O să încerc să-ți dau un răspuns în linii mari

1. În linii mari, compilarea este formată din pașii următori
  1.Analiza și verificarea codului pentru greșeli sintactice (ex. lipsește o paranteză la apelul unei funcții) și greșeli semantice (ex. apelul unei funcții ce nu a fost definită nicăieri)
  2.Producerea ”codului-obiect”, care după mai multe prelucrări devine cod ASM.

Nu pot să încadrez într-un post toate detaliile nitty-gritty ale procesului, pentru că aici e vorba de Teoria Compilatoarelor + Limbaj asamblare + Detalii specifice sistemului de operare,
până sa ajungem la fișierul executabil.

Există două zone de memorie la care are acces un program in execuție pentru scriere și citire, a.k.a pentru declarare și manipulare de variabile. Stiva și Heap(a.k.a memoria dinamică). Evident, atât stiva cât și heap-ul sunt regiuni de memorie RAM.

Variabilele locale + argumentele sau o parte din argumentele unei funcții sunt stocate pe stivă, în mod contiguu în ordinea în care sunt declarate. În exemplul tău, se vor rezerva în stivă 4 octeți ( dimensiunea unui int) + sizeof(string) octeți la execuția funcției main. La încetarea execuției funcției, memoria alocată se ”eliberează automat”.
Acesta e un proces automat, realizat de compilator, nu depinde de tine și de cele mai multe ori nu există motiv să intervii în el.
Pentru a avea acces la memoria dinamică, în linii mari vei lucra fie cu funcția ”malloc” fie cu operatorul ”new”.  Nu am să intru în detalii aici, dar basically cu ajutorul lor vei cere sistemului de operare zone de memorie din heap, de o dimensiune precizată (mai mult sau mai puțin) de tine. Sistemul de operare decide unde să aloce memoria și tu primești înapoi o adresă a.k.a un ”pointer” pentru fiecare apel de ”malloc” sau new. Cu el, vei scrie și vei citi de la acea zonă de memorie. Cade însă în responsabilitatea ta să eliberezi zona de memorie alocată atunci când știi că nu vei mai efectua operații asupra ei, folosind funcția ”free” sau operatorul delete, amandouă primind ca argument un ”pointer”.

2.Codul scris este pe hard. În urma compilării, vei avea pe hard un fișier executabil. Acel ”exe” basically și în linii mari conține cod ASM care este deja gata pentru a fi executat. Și da, cum ai spus tu, se aduce in RAM și se executa.

Nu, nu avem cum ( sau, mai bine zis, ar dura foarte foarte mult) să transformăm un exemplu de cod, chiar și de 4 rânduri, în forma finală exactă în urma procesului de compilare, pe foaie.

3. În ASM, avem posibilitatea de a defini ”etichete” în cod. Funcționează în mod similar goto-ului din C/C++.
   Basically și în linii mari, corpul unei funcții devine cod ASM, care este precedat de o etichetă compusă din numele funcției + alte caractere decise de compilator.
   Un apel al funcției ”increase(x)” ar fi ceva gen ”goto __ZNincrease__” , în linii mari.

4. În linii mari, da. Orice clasă are un constructor, orice constructor este o funcție (în linii mari), orice funcție este ”tradusă” în ASM.

Doar o mica precizare Procesorul lucreaza cu instructiuni masina, nu ASM Poti scrie cod in limbaj de asamblare , dapa care il "compilezi" cu ASM in cod masina, adica in format binar Nu mai spunem ca pe urma fisierele obiect suporta interventia linker-ului , care aduce cod din diverse librarii de functii sau doar face referinte la asemenea cod din librarii ETC O poveste fara sfarsit Nu chiar, dat subiectul e vast
Invata C++ pana una alta, dupa aia incearca ce ti-am recomandat

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Chiar daca ti se pare ciudat, asta-i un lucru bun. Se numeste abstractizare. Standardele C (si la C++ e acelasi lucru) definesc ce trebuie sa se intample daca faci scrii codul X sau Y. Nu definesc si cum ar trebui sa se intample, e treaba celor ce scriu compilatoare sa faca acest lucru. Pentru tine ca programator asta inseamna ca scrii acum o aplicatie C care face ceva si o compilezi si sub o arhitectura si sub alta considerabil diferita. Daca ai respectat standardul si n-ai cod care sa genereze undefined behaviour, se intampla acelasi lucru.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Se genereaza instructiuni specifice procesorului, instructiuni salvate intr-un "pachet" denumit fisier executabil (fiecare sistem de operare are alta structura pentru astfel de fisiere).

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Cu mici exceptii, atunci cand rulezi programe, procesorul e in mod protected cu memorie virtuala. Tine de arhitectura calculatoarelor si sisteme de operare, nu de C/C++.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Sistemul de operare tine minte asociatii intre ce pagini din memorie sunt alocate carui proces la un moment dat. Mai multe detalii in carti despre managementul memoriei specifice sistemului de operare.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Foarte multe arhitecturi impart memoria unui executabil in rulare in urmatoarele zone:

• O zona read-only unde e stocat codul ce e executat
  
• O zona read-only unde-s stocate constante definite de tine
  
• Stiva fiecarui fie de executie (variabilele locale, parametrii functiilor (nu neaparat), etc.
  
• Pagini suplimentare de memorie virtuala alocate dinamic

Toate in memorie virtuala, sistemul de operare decide daca totul incape in RAM sau mai scrie si pe HDD.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Compilarea e una, rularea e alta.
La rulare, codul e citit de pe disc, bagat in RAM si executat. Arata cam asa pentru

void increase(int& var){
var=var++;
}

 Untitled.png   17.99K   22 downloads

Mai multe inveti citind despre assembly languages.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Fiecare procesor ofera instructiuni ce au o anumita codificare in binar.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Clasa e o adunatura de cod, la compilare rezulta diverse functii (cod cu etichete de start). Instante a clasei sunt ca niste structuri de date.

Edited by dani.user, 14 September 2016 - 22:11.

Cred ca ce te intereseaza pe tine e de fapt cum functioneaza procesorul. De aici reiese si modul in care compilatorul transforma textul tau in instructiuni masina.
Am sa incerc sa-ti prezint preoblema de la compilare pana la nivel de tranzistor, dupa care o sa ma intorc inapoi spre compilare, deoarece abia dupa ce intelegi procesorul, poti intelege de ce compilatorul face anumite chestii.
Nu lua informatiile ca fiind 100% corecte, nici macar 50%. Scopul e de a intelege principiul de functionare, detaliile nici nu le cunosc si cum au spus colegii de forum sunt destul de diferite de la SO la SO, la tipul de hardware, etc... In plus memoria poate fi salvata pe disc de catre SO deoarece acesta lucreaza cu memorie virtuala.  Sunt multe procese, important e sa intelegi principiul deocamdata si fluxul. Dupa care poti cauta sa vezi exact cum se face fiecare pas.
1. Compilarea+ linkeditarea, e un proces care depinde de compilator si de sistemul de operare. Scopul acesteia e sa transforme instructiunile scrise de tine (ntr-un limbaj mai user friendly ) intr-un limbaj inteles de masina.
Rezultatul e un fisier .exe(sa zicem). Acesta contine pe langa informatii de antet (pe care sistemul de operare le interpreteaza in momentul lansarii) si codul masina, ala fiind o serie de instructiuni. Aceste instructiuni pot fi rulate direct in procesor (in afara de anumite chestii punctuale, sa facem abstractie deocamdata). Lipsesc adresele de system call, adrese care vor fi inlocuite de catre sistemul de operare la lansare.

2. Executia la nivel de sistem operare.
In momentul cand faci dublu click pe exe-ul ala, sistemul de operare aloca spatiu de memorie pentru program, completeaza adresele instructiunilor si ruleaza programul. Intr-un sistem multitasking in care mai multe programe ruleasa simultan, procesorul va lucra la programul tau in timp ce lucreaza si la celelalte programe. Sistemul de operare manageriaza ordinea in care programele au acces la procesor dupa un algoritm. Dupa ce proocesorul rontaie la programul tau, sistemul de operare poate decide sa puna programul tau in asteptare pentru ca urmeaza alt program la rand. Atunci se executa o serie de instructiuni specifice schimbarii taskului. Instructiuni cade de fapt salveaza starea programului tau urmand sa fie restaurata in momentul cand primeste iar verde. Ideea e ca intr-o anumita portiune de timp procesorul ruleaza exclusiv programul tau (un core al lui mai precis, dar sa nu ne complicam)

3. Executia la nivel de fisier executabil
Fisierul copiat in memorie de catre SO contine de fapt instructiuni scrise sub forma binara. O instructiune poate avea 1-2...n octeti. Acele instructiuni masina au fost generate de catre compilatorul tau. Secventele alea de octeti pot fi interpretate direct in instructiuni de asamblare (de catre un disassembler) dar pot fi executate si direct de catre procesor. Spre exemplu daca in fisier ai secventa de octeti 0402,(hexa), asta pentru el inseamna ca trebuie sa adune 2 in registrul lui intern numit AL, valoarea 2.
https://pdos.csail.m...gs/i386/ADD.htm
Pe site-ul asta gasesti o gramada de opcodes. OPCODES se numesc codurile zastea pentru fiecare instructiune la nivel de asamblare (assembler). Poti alege sa programezi si in limbajul de asamblare, caz in care ompilatorul (numit assembler) nu face altceva decat sa transcrie codul tau TEXT scris in OPCODES
Adica instructiunea
ADD AL, 2;
in opcodeul
0402
unde 04 inseamna ca se aduna ceva la AL, iar 02 este chiar valoarea de tip byte care se aduna (adica 2)
In cazul limbajului C, cand scrii
a=b++; (adica copii valoarea lui b in a, dupa care incrementezi
va fi transformata in limbaj de masina in ceva de genul...

mov AX 0x093203FA;  adica pune in registrul AX valoarea gasita la adresa aia... adica adresa lui b, valoare completata de sistemul de operare la lansarea programului. Sunt si alte variante, cu adresare relativa unde SO nu mai are traba, nu intru in detalii. de fapt va fi opcode-ul operatiei respective, nu textul asta assembler.

mov 0xblablabla AX; adica va pune continutul lui AX (adica ce era anterior in variabila la adresa blablabla, adica adresa variabilei a; La fel, ai un opcode pentru operatia asta format(sa zicem din 3-4 octeti) de genul 05 FA 22 17 Poti sa teuiti sa vezi exact cum se formeaza opcodes din instructiunile assembler

inc AX; Incrementeaza continutul registrului AX (la fel, ai un opcode pentru asta format din 2 octeti Instructiunile care nu necesita acces la memorie au in general opcodes mai scurte. Cele mai lungi opcodes sunt cele ce lucreaza cu valori imediate (adica aduni la o variabila sa zicem o valoare 233423, valoarea aia trebuie sa fie continuta in corpul instructiunii(OPCODE) ), sau cele ce lucreaza cu adrese (adica au acces la memorie Instructinu gen MOV, CALL, etc...) Poti cauta lista de instructiuni specifice procesorului si OPCODESurile lor in datasheetul procesorului (de ex la intel vei gasi datasheet pentru fiecare procesor)

mov AX 0x093203FA; Adica salvezi la adresa lui a, valoarea aia din AX (incrementata in instructiunea anterioara, conform cu ceea ce-si doreste programul din C.


Functie de ce urmeaza in programul tau, unele instructiuni pot sa lipseasca (spre exemplu nu folosesti niciunde valoarea lui b, etc...) Asta tine de compilator. El face optimizarile. Optimizarile sunt aranjamente optime ale instructiunilo in asamblare astfel incat programul sa nu fie afectat, dar sa mearga mai repede, fara a face chestii inutile.

4. Executia la nivel hardware.
O sa iau exemplu executia  unei instructiuni de tip
MOV AX, 0x021317.  care are un anume opcode
Sa zicem (ca mi-e lene sa ma uit)
06021317.
06  inseamna pentru procesor(sa zicem) ca trebuie sa mute valoarea care se afla la adresa precizata ulterior, in registrul intern AX
in momentul cand procesorul a citit valoare 06 el stie ca trebuie sa faca cam urmatoarele..
- sa puna pe magistrala de adrese valoarea 021317. inainte de lucrul asta, magistrala de adrese era intr-o stare de impedanta inalta (niciun alt device conectat la ea, nu o folosea)
- sa semnalizeze ca adresa e valida si apoi sa elibereze magistrala (daca magistrala e multiplexata cu aia de date, e necesar s-o lase libera pentru ca memoria s-o poata opera)
- ca raspuns, memoria demultiplexeaza adresa aia, selectand exact octetul de la adresa aia.
- varsa continutul pe magistrala de date si semnalizeaza ca si-a terminat treaba
- procesorul asculta magistrala de date. Cand datele sunt valide, copie valorile alea intr-un registru intern AX printr-o serie de operatiiuni.
Picioarele de la procesor le gasesti in datasheet. Ai acolo o gramada de semnale cu diverse semnificatii. Unele sunt mai binecunoscute de catre programatori, altele de catre electronisti. Sunt si picioruse analogice (sa zicem alea care masoara temperatura de pe cip) Sunt  si semnale multiplexate (adica un piciorus poate avea 2 functii selectabile) Arihtectura procesoarelor moderne e mult mai complexa (pentru a obtine viteza si performanta), dar poti incepe sa intelegi cum functioneaza un procesor mai simplu cum e Z80(mai simplu) sau 8086(cu care e compatibil pentiumul de acum).
https://en.wikipedia...wiki/Intel_8086


05. executia in interiorul procesorului
Odata ajunsa instructiunea din segmentul de date (aflata la adresa data de registrul IP)
Cauta sa vezi ce-s aia registri. Sunt niste variabile interne cu care procesorul lucreaza foarte repede deoarce nu e necesara adresarea (toata procedura aia complicata cu magistrala spre memorie care poate dura multi cicli de ceas) In OPCODEs registrii astia sunt codificati. Registrii interni procesorului au diverse functii, unii registri avand functii specializate (SI BP, DI, etc..), alti registri sunt mai multifunctionali (adica exista instructiuni care-i folosesc in fel si chip) Exista si un registru special de FLAGS unde exista semnificatii distincte pe fiecare bit. Este folosit la instructiuni de salt (JZ, JNZ, JP, etc...) Practic in orice bucla if/then/else din C compilatorul va inlocui cu instructiuni de salt care verifica valoarea unir anume biti din FLAGS.
Registrii sunt folositi intern de catre unitatea aritmetica si logica (ALU)
ALU selecteaza microoperatia potrivita fiecarui OPCODE si executa acea microoperatie.
microoperatiile sunt de.. adunare, incrementare, scadere, salt, ... de tot felul, unele mai simple, altele mai complexe.
Pentru fiecare tip de microoperatie, exista un circuit care ofera rezultatul potrivit. E o intreaga teorie care tine de optimizarea circuitelor digitale, dar finalmente ele sunt de fapt niste porti logice legate intr-un anume fel sa genereze raspunsul dorit in acea microoperatie.

Gasesti pe net scheme de circuite logice capabile sa faca adunari, scaderi, etc.. Cauta o carte despre arhitectura lui Z80 sau a lui 8086. O sa intelegi basicul, cum functioneaza totul pana la nivel de transistor. Sunt sceptic ca vei reusi sa intelegi un pentium pana la nivel de tranzistor, dar un Z80 se poate fara probleme daca ai inclinatii.

Fiecare poarta logica (care pot fi de tip SI NU, sau SAU NU), e facuta din tranzistori. Bipolari sau CMOS. Ai porti TTL, CMOS, etc...fiecare cu avantajele si dezavantajele lor.  Gasesti pe net schemele catorva porti logice folosite de-a lungul timpului.
Orice operatie aritmetica si logica se poate face cu un singur tip de porti logice (SI NEGAT sau SAU NEGAT), asta tine de teoria operatiilor booleene. E si aici o intreaga teorie. Circuitele se pot simplifica, dar asta e o intreaga disciplina.

Procesoarele moderne folosesc tot felul de smecherii pentru a realiza portile logice cat mai mici, dar necesita tehnologii avansate de realizarea circuitelor pe pastila de siliciu. Monocristalul este dopat si apoi sunt create punti intre diverse arii ale cipului (mici segmente de aur). Circuitele moderne trec prin sute de operatii de mascare, gravare chimica, procedeee de implant ionic, depunere metalica, oxidare, suprafete fotosensibile, etc.. toate astea pentru a obtine acele porti lofice(in principal). Evident, asta e o alta disciplina. Gasesti pe net cum se fabrica chestiile astea si mai ales cum se asigura fiabilitatea pasilor.

Procesoarele s-au complicat mult de la 386 incolo. Pentru intelegerea in detaliu e nevoie de un studiu serios pe tema.

Cam astea-s principiile, nu sunt complete, nici corecte, dar sper sa te indrume in directia corecta.

Edited by maccip, 15 September 2016 - 00:00.

AndreiCCC, on 14 septembrie 2016 - 20:48, said:

Poti folosi debuggerul sa vezi codul din spate ori poti sa-i spui compilatorului sa genereze si ASM. Scopul documentatiei unui limbaj de nivel inalt e sa te invete tehnici de aici, nu low-level (chiar daca le poate apela dupa cum ai in help detalii).
Ce vrei tu se studiaza in mai multe discipline dar principale sunt: sisteme de operare si arhitectura sistemelor de calcul. Ia carti cu acestea si te lamuresti. Numai ca durata de asimilare si documentare e mult mai mare decat a limbajului de la care pornesti, iar dincolo de curiozitatea tehnica, foarte putini vor folosi in practica (dezvoltatorii de sisteme de operare, drivere, ceva optimizari).
La facultate se studiaza (introductiv dar ai o idee) asa ceva, calculatoarele/informatica nu inseamna strict un limbaj (doua, N) ci un cumul de aspecte/detalii, de acceea programa de aici te trece prin toate cate un pic, apoi te specializezi in ce doresti.

Edited by neagu_laurentiu, 15 September 2016 - 08:51.

Problema cu assembly-ul este faptul ca in mai toate cartile (inclusiv cele ale lui Bjarne S.) nu este mentionat. In detaliu,aveti dreptate, se gaseste in Arhitectura Sistemelor de Calcul.

Pe scurt, am inteles faptul ca un cod sursa este compilat, rezultand un cod obiect care este input (impreuna cu alte coduri obiect) in linker rezultand executabilul (codul masina). Nicaieri nu mentioneaza faptul ca intre cod obiect (sau mai bine spus dupa link-editare) si cod masina(cod executabil) s-ar afla ASM.

ASM e clar ca nu poate fi executat direct de CPU, dar de ce nu se mentioneaza ,,granita" (adica din ce este generat prin asamblare, urmand ca ulterior sa devina cod executabil). In toate cartile: codul obiect trece direct in cod masina . De aceea intrebam de ASM...

Concluzionand, un cod sursa (care este cross platform) prin compilare devine cod obiect (dependent de sistem), care prin legare cu alte coduri obiect sau biblioteci, devine prin asamblare, cod ASM, si care in final devine cod executabil(masina) ?

@pale_and_pale, nu stiu de ce, dar tot timpul aveam impresia ca ASM se afla intre cod sursa si cod obiect si nu cum am spus o fraza mai sus (respectiv intre cod obiect si cod masina)... Sigur nu faci vreo confuzie?

Edited by AndreiCCC, 19 September 2016 - 00:10.

AndreiCCC, on 18 septembrie 2016 - 23:58, said:

Ba e mentionat dar depinde ce citesti. Uite in documentatia unui producator de compilatoare (in definitiv asta folosesti, nu o teorie / un concept): https://msdn.microso...y/4ks26t93.aspx
Insa documentatia limbajului de nivel inalt este conceputa pentru acesta, nu pentru aditionale. Cum in cartea unei masini din 2016 nu ti se descrie cum erau cele din 1910 sau cum functioneaza motorul, asa si aici. Cauta ce vrei unde trebuie, nu unde crezi tu ca ar trebui!

AndreiCCC, on 18 septembrie 2016 - 23:58, said:

Pai nici nu se afla. Nu se genereaza .asm ca acesta sa fie compilat! Ci direct cod masina. Exista optiune pentru mediul de dezvoltare sa genereze ASM dar asta-i la alegere si pentru a vedea tu una-alta.
Assembly language may also be called symbolic machine code. Deci poate sa nu fie 1:1, in functie de asamblor, poti gasi si mici artificii care si ele se "traduc" in cod masina.
ASM e un limbaj ca oricare altul. Ca e cel mai apropiat ca flux (si sintaxa sa zicem desi nu-i asa in realitate in raport cu nivelul vizual) de codulul masina, e alta discutie.

Edited by neagu_laurentiu, 19 September 2016 - 06:27.

Daca vrei sa ai ceva succes ca programator tre sa inveti sa folosesti uneltele care ti se pun la dispozitie fara sa-ti bati capul cu ce-i in spatele lor, de-aia sint unelte. Cind folosesti o masina de spalat te intrebi ce e in spatele cuvei si cu isi da seama ca are sau nu apa si ce se intimpla "la nivel de tranzistor"? Concentreaza-te pe ceea ce ai de rezolvat si doar in cazul in care solutia gasita nu este suficient de buna, ca performanta de exemplu, poti sa incepi sa-ti bati capul cu ceea ce se intimpla "in spate", poate reusesti sa faci ceva mai bun (chestie care o oricum extrem de improbabila, pentru ca toata aceste unelte, cum ar fi un compilator, sint optimizate pina la dumnezo de niste oameni infinit mai priceputi in domeniu decit ceea ce gasesti pe softpedia). Cu alte cuvinte, nu mai alerga dupa cai verzi pe pereti

O intrebare de-acolo e totusi utila si anume cum se aloca memoria si anume random? Raspunsul este not really, fiecare sistem de operare / compilator are proria logica, dar asta nu elimina dezastrele care se pot intimpla. Doua mari dezavantaje ale alocarii dinamice sint fragmentarea si memory leaks. Pentru un program care ruleaza pe un home computer, cu 15 miliarde de infinite de gigi, unde daca crapa pur si simplu il pornesti din nou, nu reprezinta o problema prea mare, insa daca e vorba de exemplu de ceva sistem care controleaza ceva cacat la un avion, care daca o ia razna da cu respectivul avion de pamint, deja devine o mare problema. De aceea alocarea dinamica in asemenea sisteme este pur si simpul... interzisa

Multumesc tuturor pentru rabdare!

Deci ASM este un limbaj ca oricare altul, de sine statator, care nu are nicio treaba cu alte limbaje de programare. Nu este un limbaj intermediar intre high/mid level languages si crearea codului masina (in sensul trecerii unui cod high-level in cod exec.). Fiecare limbaj (C,Java,C#,Assembly) are firul lui pana la codul masina. Avantajul este ca dintre toate limbajele, ASM este cel mai apropiat de hardware si totodata fiecare arhitectura are limbajul ASM propriu.

Dar nu se ,,amesteca" cu alte limbaje. (doar daca vrem noi, in IDE putem solicita ASM, dar cursul firesc nu trece pe ASM).

Inclusiv pe acest topic sunt mai multe idei contradictorii ceea ce m-a cam   . Plus ca si in liceu profesorul ,,baga" assembler intre codul sursa si codul final (si nu in sensul ca este ,,mai apropiat de hard" ci ,,in fluxul de transfer spre cod executabil")...

Edited by AndreiCCC, 19 September 2016 - 10:40.

AndreiCCC, on 19 septembrie 2016 - 10:35, said:

Pentru simplitatea intelegerii notiunilor poate ca s-a exprimat asa.
Uite un cod in ASM:

ADD EAX,1

Echivalentul in cod masina pe x86 (exprimat in hexa):

83C001

De ce ar genera un compilator sanatos la cap in ASM ca apoi sa apeleze pe altu' sa obtina "balarii" specifice ? Nu spun ca nu s-a practicat odata sau nu o fi pe undeva unul de samanta asa! Dar actualele  (care genereza cod nativ) nu mai au acest obicei, stiu direct a obtine. In acest caz avem o relatie unu la unu, oricand gasesti codul masina poti sa asociezi cu textul ASM cat si invers. De aceea se confunda cumva daca faci abstractie unele aspecte.
Plecand de la un cod simplu in C obtii multe insiruiri din astea "ciudate" dar e treaba compilatorului sa stie ce face acolo.

Edited by neagu_laurentiu, 19 September 2016 - 11:18.

neagu_laurentiu, on 19 septembrie 2016 - 11:14, said:

Da este logic, si multumesc inca o data. Stii care e problema? Cel putin in Romania, daca intrebi un profesor (de liceu, de facultate), baga assembler-ul in cursul (in fluxul informational) dintre un limbaj (precum Java,C, sau orice alt limbaj mid-high level) si codul masina (1 si 0) - vezi poza de mai sus. Pe cand, realitatea e cum spui tu (spuneti voi).

Iti spune ca orice e high trece la un moment dat in ASM. La fel si foarte multe surse care par de incredere.

Multumesc inca o data.

Faci confuzie intre limbaje:
1. Fie inveti assmebler (care e asemanator intre arhitecturi, dar nu identic), iar codul tau devine direct cod executabil (cu 0 si 1 cum zici).
2. Fie inveti C/C++/sau ce vrei tu, iar codul tau devine cod obiect, apoi cod masina. Ca ai un feature care transforma un cod masina in assembly (sau invers: asamblorul si dezasamblorul) in IDE, a altceva.

Cand vorbim de 2. spunem portabilitate, cand vorbim de 1. spunem puternic neportabil.
E ca si cum ai avea un feature care transforma un cod Java in C (pp prin absurd). Dar Java nu trece in C inainte de deveni executabil (cum nici invers....). Fiecare cu ....
@Andrei, de unde ai pozele alea?

Edited by Rhesus, 19 September 2016 - 11:41.