![]() |
Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
Programmers Debate

#19
Posted 09 December 2008 - 18:13

Ca sa ilustrez mai bine ce am zis in post-ul trecut, iata o poezie ironica a lui Dennis Ritchie (tipul care a inventat C si care a "co-inventat" UNIX):
Quote Empty your memory, with a free like a pointer. If you cast a pointer to a integer, it becomes the integer, if you cast a pointer to a struct, it becomes the struct. The pointer can crash… and can Overflow…. Be a pointer my friend… Cheers, Bogdan |
#20
Posted 09 December 2008 - 23:31

Quote Pentru e mult mai eficient sa ai parametrii in registre atunci cand ai loc decat sa ii pui pe stiva si sa ii scoti apoi. Nu uita ca viteza memoriei e complet patetica comparativ cu cea a registrelor, avand in vedere ca ele sunt aflate fizic in procesor. Nici cache-ul nu e o solutie cu mult mai buna. __fastcall nu este cu mult mai rapid decat celelalte calling conventionuri. Nu pune decat primii 8 bytes (pe ECX si EDX) din lista de argumente pe registrii, restul ii ia de pe stiva. In alte calling convention-uri parametrii sunt pop-uiti de pe stiva. Diferenta e extrem de minora, semnificativa la 'jde mii de apeluri. Daca memoria cache (care este cea mai rapida dintre toate) nu este "solutia", atunci care este aceea? Intr-un sistem cu multitasking, nici nu ai de unde sa stii daca urmatorul "fetch" care il vei face dintr-un registru nu a fost de fapt pus in ram sau cache si repus la loc thread-ului tau curent in cadrul aceluiasi apel de functie. Asadar __fastcall e o "treaba", insa nu o "afacere". Quote Pentru ca pentru un compilator de aplicatii ce ruleaza sub mediul Windows, asamblarea e considerata nesigura. Limbajele precum Java si C# au fost inventate tocmai pentru a ne scapa de anumite concepte cum ar fi pointerii, astfel scapand multe aplicatii de diverse erori. Java - C# = RAD Managed-ul este doar un aspect implicit. Erorii la pointeri apar dintr-o cauza singulara: cod prost, scris de developeri... naivi, sau complexitate mare generata de un design prost. O data ca a aparut garbage collectorul, fani programarii "usuratice" s-au ridicat din tribune in aplauze sustinind (precum tu sustii) ca asta e viitorul. Sunt unii (Linus Torvalds si alti fani C) care sustin ca OOP-ul este un "overhead" nejustificat, ce sa mai spunem de managed-ul tau. Un OS Developer ca tine, ar fi trebuit sa tarasca in noroi C# Java si sa ridice in slavi asm - C, nu invers.. Quote C++ nu e low-level, ci middle-level spre high-level. Probabil te referi la C. Nu exista decat low si high. Ma bucur de Bjane ca a creat un limbaj care este atat de "natural" incat e confundat cu limbaje high-level. Abstractizarea C++ este atat de "customizabila" si iti confera atata "putere" incat nu poate fi considerat high level, ci low-level. Sub C++ nu am nici un layer, decat un compilator, exact ca si C. So, what's high? In primul rand, notiunea de low si high level este o notiune relativa, o paradigma daca vrei. Candva intr-adevar C++ era intalnit sub notiunea de "high", insa acum lucrurile s-au schimbat. E simplu de inteles de ce nu? Daca C++ e "high-level" java ce mai e? Sky scraper? Quote Odata cu cresterea puterii de calcul, avem optiunea de a face aplicatiile mai sigure, ceea ce a devenit o prioritate mai mare in ziua de azi. Citeste mai atent ce am scris. Da, intradevar, sunt si mai "sigure", pentru cei care daca ar avea un pointer "pe mana", ar genera un dezastru. Quote Fiind type-safe, poate sa ne scape de anumite erori in aplicatii, specifice pointerilor. Un exemplu este buffer overrun-ul. ![]() Un design bun nu are nevoie de type-safety. De exemplu RTTI-ul nu este folosit foarte mult de programatorii "versati" C++, desi pare un instrument care te scapa de multe "belele". Edited by madlex, 09 December 2008 - 23:53. |
#21
Posted 10 December 2008 - 00:17

Intr-un sistem cu multitasking, nici nu ai de unde sa stii daca urmatorul "fetch" care il vei face dintr-un registru nu a fost de fapt pus in ram sau cache si repus la loc thread-ului tau curent in cadrul aceluiasi apel de functie. Asadar __fastcall e o "treaba", insa nu o "afacere". Te contrazic. Sigur, vei avea TLB misses sau chiar cache misses, dar cu un algoritm de page replacement eficient, OS-ul va evita asta in cele mai multe cazuri. In plus, in sistemele cu SMT (sau hyperthreading [HT], cum vrea Intel s-o numeasca), __fastcall evident va fi cu atat mai performant cu cat se pot retine 2 stari simultan. Quote Daca memoria cache (care este cea mai rapida dintre toate) nu este "solutia", atunci care este aceea? Cache-ul nu e cea mai rapida memorie. TLB-ul este mai rapid, iar apoi evident, registrele. Si da, registrele sunt memorie, nu doar manipulatori. De cele mai multe ori asa vei avea impresia pentru ca nu ai suficiente incat sa salvezi mai stiu eu ce acolo, dar defapt stochezi informatie acolo. Tot ce trece prin cache si prin RAMi, daca e sa fie folosit, va fi folosit prin intermediul registrelor asa ca totul este o "iluzie" comerciala (ar costa cam mult un procesor cu 1 GB RAM) care te face sa crezi ca ai mai multe registre, cum si RAMii te fac sa crezi ca ai mai mult cache. Quote Considerata nesigura? aoleu.. Java - C# = RAD Managed-ul este doar un aspect implicit. Nici vorba. N-are nici cea mai mica legatura. RAD e u interfata frumoasa care iti scrie codul pentru tine. Codul managed este un cod binar (adica compilat, nu cod sursa) facut de asa natura incat tradus in codul nativ al procesorului sa respecte anumite reguli. Quote Erorii la pointeri apar dintr-o cauza singulara: cod prost, scris de developeri... naivi, sau complexitate mare generata de un design prost. O data ca a aparut garbage collectorul, fani programarii "usuratice" s-au ridicat din tribune in aplauze sustinind (precum tu sustii) ca asta e viitorul. Sunt unii (Linus Torvalds si alti fani C) care sustin ca OOP-ul este un "overhead" nejustificat, ce sa mai spunem de managed-ul tau. Un OS Developer ca tine, ar fi trebuit sa tarasca in noroi C# Java si sa ridice in slavi asm - C, nu invers.. Treaba mea nu e sa educ userii sa devina programatori. Consider ca un calculator ar trebui sa poate fi folosit pe cat de bine posibil de un utilizator oarecare. Nu ar trebui sa invete nimeni programare ca sa puna calculatorul sa faca o anumita chestie, dar hey, deocamdata asta e situatia. Managed code is a step in the right direction. Pe langa asta, cand lucrezi la un ditamai proiectul erorile sunt inevitabile. Daca ne putem folosi de un limbaj mai sugestiv, de ce sa n-o facem? Procesorul nu executa cod C. Habar n-are ce e o acolada sau un bloc de instructiuni. Nu o sa ma apuc niciodata sa fac un editor video intr-un limbaj de asamblare. Cu atat mai inalt nivelul, cu atat mai usor, cu atat mai bine. Quote Eu zic ca este entry-level. Nu exista decat low si high. Ma bucur de Bjane ca a creat un limbaj care este atat de "natural" incat e confundat cu limbaje high-level. Abstractizarea C++ este atat de "customizabila" si iti confera atata "putere" incat nu poate fi considerat high level, ci low-level. Sub C++ nu am nici un layer, decat un compilator, exact ca si C. So, what's high? In primul rand, notiunea de low si high level este o notiune relativa, o paradigma daca vrei. Candva intr-adevar C++ era intalnit sub notiunea de "high", insa acum lucrurile s-au schimbat. E simplu de inteles de ce nu? Daca C++ e "high-level" java ce mai e? Sky scraper? Exista mai multe defapt. Middle-level am denumit-o eu pe moment pentru a face diferenta in "inaltime". Exista si very high-level si altele. Quote Un design bun nu are nevoie de type-safety. De exemplu RTTI-ul nu este folosit foarte mult de programatorii "versati" C++, desi pare un instrument care te scapa de multe "belele". Un design bun nu inseamna si o implementare buna. Pot sa gandesc bine dar sa nu fiu capabil sa scriu cod. Sau la fel de bine, sa fiu capabil dar sa nu am experienta/cunostintele necesare si sa nu am timp/chef sa capat asa ceva. Ar trebui sa imi fie imposibil sa scriu o aplicatie? De ce? Pentru ca programatorii sunt mandrii ca sunt programatori? The PC is a tool and the sole purpose of a tool is to get the job done as conveniently as possible for whoever is using it, right? Cheers, Bogdan Edited by Love4Boobies, 10 December 2008 - 00:30. |
#22
Posted 10 December 2008 - 00:32

Managed code is a step in the right direction. Ce-mi place faza cu managed-ul in sus si-n jos dar cand vine treaba sa-l pui la ceva serios iti striga in gura mare: da' tu n-ai auzit de unsafe in C# & pointeri ? Ca nu i-am inclus degeaba si aici ! |
#23
Posted 10 December 2008 - 00:52

Cine sustine asta ? Ce-mi place faza cu managed-ul in sus si-n jos dar cand vine treaba sa-l pui la ceva serios iti striga in gura mare: da' tu n-ai auzit de unsafe in C# & pointeri ? Ca nu i-am inclus degeaba si aici ! Cine sustine ca C este o decizie buna as opposed to assembly? Singurul motiv pentru care exista pointeri in C# este ca sistemele de operare curente se folosesc de niste tehnologii invechite care nu le permit sa se descotoroseasca complet de concept. Dar intr-o buna zi probabil ca nu va mai fi aceeasi poveste... hopefully curand... Cheers, Bogdan |
#24
Posted 10 December 2008 - 11:20

Quote Te contrazic. Sigur, vei avea TLB misses sau chiar cache misses, dar cu un algoritm de page replacement eficient, OS-ul va evita asta in cele mai multe cazuri. In plus, in sistemele cu SMT (sau hyperthreading [HT], cum vrea Intel s-o numeasca), __fastcall evident va fi cu atat mai performant cu cat se pot retine 2 stari simultan. Vino cu un test pe __fastcall pe un multithreaded OS si o sa te convingi singur. Nu vorbim de teste pe un procesor care implementeaza o tehnologie aparte. Ca asa facem teste pe AMD pentru Hyper Transport si in anumite cazuri vedem ca "ceva" ne iese mai bine si interpretam ca atare. Ma intereseaza rezultatul generic, nu pe Intel cu HT. Citeste si tu ce inseamna TLB inainte (te rog eu): Quote A Translation lookaside buffer (TLB) is a CPU cache that is used by memory management hardware to improve the speed of virtual address translation. All current desktop and server processors (such as x86) use a TLB. A TLB has a fixed number of slots containing page table entries, which map virtual addresses onto physical addresses. It is typically a content-addressable memory (CAM), in which the search key is the virtual address and the search result is a physical address. If the requested address is present in the TLB, the CAM search yields a match very quickly, after which the physical address can be used to access memory. If the requested address is not in the TLB, the translation proceeds using the page table, which is slower to access. Furthermore, the translation takes significantly longer if the translation tables are swapped out into secondary storage, which a few systems allow. TLB-ul nu este o memorie propriu zisa, este o tabela. De asemenea nici registrii nu ii putem categorisii ca memorie. Deci, revin, care e varianta mai buna decat cache-ul? (asupra careia oricum nu ai acces) Quote Nici vorba. N-are nici cea mai mica legatura. RAD e u interfata frumoasa care iti scrie codul pentru tine. Codul managed este un cod binar (adica compilat, nu cod sursa) facut de asa natura incat tradus in codul nativ al procesorului sa respecte anumite reguli. RAD este un concept. Nu o interfata graphica, nu un layer, nimic. Un concept "Rapid application development" C# inseamna RAD si Java de asemenea. Codul managed e CE??? Ce cod binar? Ce vorbesti tu acolo? Managed inseamna ca cineva sau ceva, iti creeaza managementul memoriei pentru tine. Atat. Quote Pe langa asta, cand lucrezi la un ditamai proiectul erorile sunt inevitabile. Quote Exista mai multe defapt. Middle-level am denumit-o eu pe moment pentru a face diferenta in "inaltime". Exista si very high-level si altele. Dar tehnic raman doar doua: high si low. Acel "very" high-level eu il vad ca un high level cu un adverb pe langa el "very" introdus pentru sublinierea distinctiei. Formularea nu am intalnit-o niciodata intr-un document de specialitate. Tu poate citesti altceva.. Quote Un design bun nu inseamna si o implementare buna. Pot sa gandesc bine dar sa nu fiu capabil sa scriu cod. Quote Sau la fel de bine, sa fiu capabil dar sa nu am experienta/cunostintele necesare si sa nu am timp/chef sa capat asa ceva. Ar trebui sa imi fie imposibil sa scriu o aplicatie? Nu fi asa dur cu ele.. Quote Cine sustine ca C este o decizie buna as opposed to assembly? Singurul motiv pentru care exista pointeri in C# este ca sistemele de operare curente se folosesc de niste tehnologii invechite care nu le permit sa se descotoroseasca complet de concept. Dar intr-o buna zi probabil ca nu va mai fi aceeasi poveste... hopefully curand... Eu zic sa scoatem ram-ul cu totul, oricum era inutil. Lasam doar CPU-ul cu cache-ul, TLB-ul si registrii si eventual il conectam direct la sursa.. (mainboard free) Hai sa fim seriosi, eu zic ca fanteziile astea nu duc nicaieri... Cheers |
#25
Posted 10 December 2008 - 11:57

So, what's high? ![]() Am citit, m-am amuzat, iar parerea mea la toate aspectele este clasicul: IT DEPENDS ![]() (nu vei scrie un OS in C# asa cum nu vei scrie un browser in ASM; nu exista "perfect", doar "perfect pt proiectul X cu prioritatile Y"). Bineinteles o prioritate poate fi si misionarea unui anumit limbaj sau tehnlogii ![]() ![]() |
#26
Posted 10 December 2008 - 13:45

Ma contrazici degeaba. Vino cu un test pe __fastcall pe un multithreaded OS si o sa te convingi singur. Nu vorbim de teste pe un procesor care implementeaza o tehnologie aparte. Iti dai seama ca multiplexul de threaduri se face la cateva nanosecunde, probabil intre timp au loc deja mai multe apeluri la diverse functii cu __fastcall. Prin urmare, e un avantaj. Registrele sunt mai rapide decat stiva care e in RAMi. Punct! Quote Citeste si tu ce inseamna TLB inainte (te rog eu): TLB-ul nu este o memorie propriu zisa, este o tabela. De asemenea nici registrii nu ii putem categorisii ca memorie. Deci, revin, care e varianta mai buna decat cache-ul? (asupra careia oricum nu ai acces) Stiu ce e TLB-ul. Nonetheless e memorie. Indiferent ce e stocat acolo. E un layer de cache pus peste cache si este mai rapid decat el. Nu am zis ca poti tu sa-ti pui valorile proprii acolo. Quote (Ce-mi plac astia care raspund cu "Nici vorba", "Fals", "Ai gresit" si apoi revin ei cu o explicatie si "mai gresita") RAD este un concept. Nu o interfata graphica, nu un layer, nimic. Un concept "Rapid application development" C# inseamna RAD si Java de asemenea. Un concept care presupune ce? Un mediu INTERACTIV de programare. Click here pt detalii. Quote Codul managed e CE??? Ce cod binar? Ce vorbesti tu acolo? Managed inseamna ca cineva sau ceva, iti creeaza managementul memoriei pentru tine. Atat. Managed code e exact ce am spus. Clicky! Quote Tu poti categorisi cum doresti limbajul. Putem introduce aici pe thread-ul asta, si notiunea de limbaj "misto". Dar tehnic raman doar doua: high si low. Acel "very" high-level eu il vad ca un high level cu un adverb pe langa el "very" introdus pentru sublinierea distinctiei. Formularea nu am intalnit-o niciodata intr-un document de specialitate. Tu poate citesti altceva.. Daca nu vrei sa ma crezi pe mine pe cuvant, poate ii crezi pe cei de la ACM. Click aici, pt un exemplu. Quote Deci, rezumam. Limbajele managed sunt pentru cei fara chef/timp si fara experienta si cunostinte. Nu fi asa dur cu ele.. Si lipsa de cunostinte e ceva rau? Nu ar trebui sa fiu programator ca sa ma pot folosi asa cum vreau de PC. O sa ajungem si acolo... Quote Te rog cum ne descotoresti tu de pointeri pe noi (astia invechiti)? Eu zic sa scoatem ram-ul cu totul, oricum era inutil. Lasam doar CPU-ul cu cache-ul, TLB-ul si registrii si eventual il conectam direct la sursa.. (mainboard free) Exista un proiect care chiar incearca sa se scape de RAMi. RAMii sunt o chestie economica. Daca ar fi sa ne luam dupa performante, ar fi contopiti direct cu procesorul. Vezi IRAM. Nu incerc sa ma "descotorosesc" de pointeri, incerc sa zic ca aplicatiile ar trebui facute pe cat de sigur posibil. Puterea de calcul ne permite sa avem diverse layere care fac tuturor viata mai usoara, nu doar initiatilor in ale programarii.
(nu vei scrie un OS in C# asa cum nu vei scrie un browser in ASM; nu exista "perfect", doar "perfect pt proiectul X cu prioritatile Y"). Oh, dar te contrazic! Vezi SharpOS si Singularity. Cheers, Bogdan Edited by Love4Boobies, 10 December 2008 - 14:01. |
#27
Posted 10 December 2008 - 14:16

Amice, esti incoerent si imi pierd timpul cu dublu explicatii..
Quote Stiu ce e TLB-ul. Nonetheless e memorie. Indiferent ce e stocat acolo. E un layer de cache pus peste cache si este mai rapid decat el. Nu am zis ca poti tu sa-ti pui valorile proprii acolo. TLB-ul si chiar cache-ul nu iti sunt accesibili. Nu are sens sa vbim de ele, corect? Bun. Quote Un concept care presupune ce? Un mediu INTERACTIV de programare. Click here pt detalii. Quote Managed code e exact ce am spus. Clicky! Quote Daca nu vrei sa ma crezi pe mine pe cuvant, poate ii crezi pe cei de la ACM. Click aici, pt un exemplu. High si low-level sunt criteriile dupa numarul de layere care "zace" sub limbajul respectiv. Ce mai pui tu pe langa "foarte/very" sau "slab/lite" sunt doar adverbe care intaresc, sublinieaza conceptul. Ce mi-ai dat tu mie intareste si mai mult ce am spus. Aratami un document oficial in care caracterizeaza java spre ex ca very high level, sau middle level cum ai spus tu. Te rog.. Quote Si lipsa de cunostinte e ceva rau? Quote Exista un proiect care chiar incearca sa se scape de RAMi. RAMii sunt o chestie economica. Daca ar fi sa ne luam dupa performante, ar fi contopiti direct cu procesorul. Vezi IRAM. Quote Oh, dar te contrazic! Vezi SharpOS si Singularity. Singularity are baza kernelului scrisa in C si asm. Mai gandeste-te. Cat timp procesorul nu suporta cod C# nu vei vedea os-uri in C# decat proiecte experimentale. Oh.. Eu sunt mai pragmatic de fel, ma retrag din discutia cu "rami pe carcasa",OS-uri si kernele in C# (dar cache-ul este lent ![]() cu RAD-uri drept GUI etc. Nu am atata putere de creatie. Cheers PS: interesanta statistica din pagina anterioara a lui neagu_laurentiu. Felicitari. |
#28
Posted 10 December 2008 - 14:32

TLB-ul si chiar cache-ul nu iti sunt accesibili. Nu are sens sa vbim de ele, corect? Bun. Ce nu iti suuunt? ![]() Quote Mai citeste o data "Rapid application development (RAD) is a software development methodology.". Te-ai parlit singur. N-am spus ca nu e o metodologie. Am spus doar ce presupune ea. Quote Pentru tine ramane exact ce ai spus. Tipic... Quote Ti-am mai spus o data "ADVERB". E ca si cum spun este un "foarte motor". High si low-level sunt criteriile dupa numarul de layere care "zace" sub limbajul respectiv. Ce mai pui tu pe langa "foarte/very" sau "slab/lite" sunt doar adverbe care intaresc, sublinieaza conceptul. Ce mi-ai dat tu mie intareste si mai mult ce am spus. Aratami un document oficial in care caracterizeaza java spre ex ca very high level, sau middle level cum ai spus tu. Te rog.. "foarte motor" nu are sens gramatical, pe cand "very high" da. Si nu este adverb, ci adjectiv. Nonetheless, very high se accepta la unele limbaje la care nu se accepta denumirea high, indiferent ca sunt precedate sau nu de adjective. Sunt denumiri oficiale, nu menite doar sa-ti curga ochii dupa ele. Quote Si modularitatea cum o vezi? Economic vbind evident. Citeste ce scrie pe pagina si vei vedea (linkul in postul meu anterior). Quote Oh, dar te contrazici singur. Singularity are baza kernelului scrisa in C si asm. Mai gandeste-te. Cat timp procesorul nu suporta cod C# nu vei vedea os-uri in C# decat proiecte experimentale. Oh.. Nu. Singularity are tot kernelul scris in Sing# (o extensie a Spec#, care e o extensie a C#). In asamblare e scris bootstrap-ul, iar in C++ e scris HAL-ul (care aici inseamna Bartok). Quote Eu sunt mai pragmatic de fel, ma retrag din discutia cu "rami pe carcasa",OS-uri si kernele in C# (dar cache-ul este lent ![]() cu RAD-uri drept GUI etc. Nu am atata putere de creatie. Nu am spus ca RAD-ul este un GUI. Dar da, iti ofera o interfata vizuala de programare. Cheers, Bogdan |
#29
Posted 10 December 2008 - 15:13

Quote Ce nu iti suuunt? smile.gif Afla ca iti sunt... Nu in acelasi fel ca memoria, dar iti sunt. Bagi chestii in cache daca vrei dupa poftele tale, iar daca vrei le "blochezi" acolo. In plus, ai auzit de write-back si write-through? TLB-ul il poti flush-ui or whatever toata ziua. Si afla ca registrii sunt cea mai mica forma de memorie (as opposed to what you said) din ierarhia de memorii. As opposed to what I said what? Quote N-am spus ca nu e o metodologie. Am spus doar ce presupune ea. Interfata e un termen generic. Fi mai explicit atunci. Quote Sunt denumiri oficiale, nu menite doar sa-ti curga ochii dupa ele. Arata-ne unde.. Quote Nu. Singularity are tot kernelul scris in Sing# (o extensie a Spec#, care e o extensie a C#). In asamblare e scris bootstrap-ul, iar in C++ e scris HAL-ul (care aici inseamna Bartok). Nici macar C++ fiindca ii trebuia un mic run-time, mult mai mare decat in cazul C-ului. E un thread in care putem bate campii, de acord, dar ma asteptam la o limita. Am zis ca ma retrag. Te rog. |
|
#30
Posted 10 December 2008 - 15:30

Si zici ca va veni vremea cand cu toti ne vom uita in codul Windows-ului bazat pe CIL...
![]() |
#31
Posted 10 December 2008 - 15:35

Oh, dar te contrazic! Vezi SharpOS si Singularity.
Si zici ca va veni vremea cand cu toti ne vom uita in codul Windows-ului bazat pe CIL... ![]() La gunoi cu pointerii, they're EVIL! ![]() Edited by OriginalCopy, 10 December 2008 - 15:39. |
#32
Posted 10 December 2008 - 15:36

Si zici ca va veni vremea cand cu toti ne vom uita in codul Windows-ului bazat pe CIL... ![]() Probabil ca nu prea curand. Singularity are codul bazat pe CIL; Windows nu poate face asa ceva pt ca ar insemna sa renunte la toate aplicatiile care ruleaza sub el, ceea ce n-ar fi o idee foarte desteapta. La urma urmei, lumea cumpara un sistem de operare pt aplicatiile care vor rula sub el, nu pt ca e un sistem de operare super-sigur si cu un design "bengos". It's all marketing... |
#33
Posted 10 December 2008 - 15:51

It's all marketing... Stau si ma intreb de ce alte OS-uri din lumea sta, care ruleaza de la PC-uri la mainframe-uri nu au fraternizat cu ideile acestea revolutionare ?! Avem doua puncte: procesorul si omul. Prin doua puncte trece o dreapta. Daca introducem in ecuatie alt treilea punct, masina virtuala, de cand prin trei puncte trece cea mai scurta "dreapta" ? |
#34
Posted 10 December 2008 - 22:28

Mi-e lene sa mai fac quote-uri si toate cele pentru ca sunt in graba. Doar cateva precizari rapide:
1) Nu am oficializat nicio denumire. Ti-am dat chiar un link de la ACM care descria un limbaj "very high level". Dealtfel, o scurta cautare pe Google si/sau Wikipedia iti va arata ca am dreptate. 2) Am dreptate si in cazul Singularity. Nu stiu cine si ce a scris pe alt thread dar daca a scris asta, a gresit. Imi pare rau, dar sunt foarte la curent cu subiectul. 3) Exista alte sisteme de operare care imbratiseaza CIL si tocmai am dat SharpOS ca exemplu. Dealtfel exista sisteme de operare care merg pe Java (care are acelasi principiu, dar ca o implementare mai putin grozava) si chiar procesoare care ruleaza Java ca bytecode nativ. Mai documenteaza-te tu. 4) Pentru a face un OS in C# you do need some setting up, dar nu mai mult de 100 de linii de cod intr-un limbaj la nivel mai low so drop it cu dezavantajele. Sunt mult mai multe avantaje decat dezavantaje. Unul din ele e posibilitatea de a renunta la vestita problema a microkernelilor CPL=0->CPL=3->CPL=0 sau IPC problematic. De ce? Pentru ca totul poate rula in acelasi spatiu "hardware" de adresare, totul fiind software, motiv pt care CIL nu este atat de lent cat este sub Windows. 5) @neagu_laurentiu: te tot plangi ca nu iti ofer exemple si/sau explicatii. Am umplut de link-uri pe-aici. Te-ai obosit sa verifici vreunul din ele sau doar vrei sa ai mai multe post-uri in forum. Stiu foarte clar despre ce vorbesc. Cat despre cliché-ul cu dreapta... ai auzit de geometrie ne-euclidiana? ![]() Cheers, Bogdan Edited by Love4Boobies, 10 December 2008 - 22:52. |
#35
Posted 10 December 2008 - 22:47

Link-urile tale sunt arhicunoscute de orice pasionat al informaticii...
Eu ma leg cu pointerii de gat si ma arunc in balta... numai ca s-ar putea sa ma scoata la suprafata fara voia mea ![]() |
|
#36
Posted 10 December 2008 - 22:54

Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users