Jump to content

Kā konkrēti izpaužas C++ valodas tuvums "dzelžiem".


Raimonds1
 Share

Recommended Posts

Man tāds jautājums - kā konkrēti izpaužas C++ valodas tuvums "dzelžiem". 

Kā vienu no piemēriem saprotu to, ka skaitļi netiek definēti kā jebkāds skaitlis, raksti ko gribi, bet gan katram mērķim definē savādāk 

int - integer ("vesels skaitlis"), kura vērtības var būt no -2147483648 līdz +2147483648 - integrer sastāv no četriem baitiem (32 bitiem) ar skaitli, kam max vērtība ir 256*256*256*256 = 4294967296, negatīvām vērtībām dalīta uz pusi  1bits zīmes saglabāšanai. 
float -peldošā punkta skaitlis, var saturēt skaitļus ar punktu (pī - 3.141592), saglabā skaitlis 3141592 un punkta atrašanās vietu šajā skaitlī. Sastāv arī no 4baitiem (32bitiem). 
double - dubulti precīzs peldošā punkta skaitlis, aizņem 2x vairāk vietas. 8baitiem (64bitiem). 
char -character, satur simbolu (piem. 'a','<'), viens char mainīgais aizņem 1 baitu (8biti). 
bool -boolean var būt tikai 0 un jebkurš skaitlis, kas nav nulle (jeb true un false),  atmiņā tas aizņem 8bitus.

 

Es to saprotu kā iespēju netērēt resursus, ja programmai būs jāskaita āboli grozā vai jārēķina algas gada mēnešos un, ieprieksnorādot ar kādiem skaitļiem būs darīšana, tie piesaistīti vienkāršākie iespējamie resursi.

 

Kur vēl izpaužas C++ rūpes par resursu taupīšanu un darbības ātrumu?

Link to comment
Share on other sites

ImissimI

Vienkārši sakot, jo ar C/C++ ir iespējams uzrakstīt un nokompilēt kodu, kas būs darbināms "pa taisno" uz konkrētas arhitektūras un nebūs no kaut kā 'atkarīgs' - interpretators, papildus bibliotēkas, vai kas cits.

 

Un low-level jau var būt arī lēns, rijīgs, neglīts, bet vienalga skaitīsies low-level, jeb tuvs "dzelžiem".

 

BTW - diskusija par "vai un kā C++ ir/skaitās low-level valoda" ir bezmaz filozofisks jautājums, jo kur tad novilkt to svītru mūsdienās?

Labots - ImissimI
Link to comment
Share on other sites

Mezavecis

Netērējot dzelžu resursus, tu tērē programmētāju resursus, lai visas minētās izmaiņas ieviestu iegūstot izmaiņas, kas minimāli ietekmē sistēmas darbību. Ir jāsaprot mērķis, kam tas ir vajadzīgs, kāpēc vajadzīgs. Darbības ar skaitļiem ir varbūt 1% no visiem resursiem. Visi pārējie resursi aiziet, lai izvilktu datus no datu bāzes un saglabātu tajā, kurus savukārt pilnīgi un noteikti nevari optimizēt dzelžu līmenī, jo tādas iespējas vienkārši nav. Protams, ka miljonu integer lauku sarēķināt ir daudz ātrāk nekā miljonu double, tāpēc jau ir tāds IT arhitekts, kas saplāno optimālu risinājuma struktūru.

 

Es to saprotu kā iespēju netērēt resursus
Link to comment
Share on other sites

Raimonds1
(labots)

Nu es biju domājis, ka C++ nav vienkārši Number, bet gan visi tie int, float, double, char utt. kas liek programmētājam iespringt, kad kuru lietot un sistēmai savukārt ļauj nelietot kaut kādu gatavu mašīnu, kas  spēj rēķināt līdz kurai tur zīmei aiz komata, kad jāsaskaita divciparu skaitļi.

 

Tātad, varēja būt prasti number, bet ir vesels mainīgo komplekts.

 

Kur vēl ir tādas vietas, kur it kā varēja rakstīt prasti kaut ko vienu, bet ir vesels komplekts, no kā izvēlēties? Tipa, programmētājam jāzina, lai mašīnai vieglāk un programma mazāka.

 

es saprotu ka C++ nav Assembler, bet C un C++ laikam ir tās nākamās tuvākās mašīnai.

Labots - Raimonds1
Link to comment
Share on other sites

ImissimI

Mežaveci, visa programmēšanas pasaule taču neaprobežojas ar tabulu bīdīšanu sudi-tudi priekš enterpraisa un otrkārt šis jau nav jautājums par ir jēga vai nav.

 

Somebody, varbūt, bet tad atkal, kas kas tad ir, ja - http://www.reddit.com/comments/308z0q

Link to comment
Share on other sites

Mezavecis
ImissimI

Ja rodas jautājumi par resursiem priekš mūsdienu sistēmām, kas izpilda miljardiem operāciju sekundē, tad pilnīgi noteikti nav runa par zemā līmeņa risināmu, kurš no gaisa izrauj nenormālu skaitļu jūru un kaut ko analizē. Algu rēķināšanā, kas bija minēts 1. postā, 100% šādu problēmu nevar būt, pretējā gadījumā programmētājs neatrodas savā vietā. Es neticu, ka tēmas autors, izracis kādu arhaisku programmu un tagad mēģina kaut ko optimizēt. 

 

 

Raimonds1

Izskaidro cilvēcīgā valodā, ko vēlies panākt un tad risināsim "problēmu". Pagaidām es nesaprotu, uz ko iespringt. Patērēt stundu, lai optimizētu sistēmu par 0.01%, ir stulbums. 

Link to comment
Share on other sites

Javā arī ir visādi skaitļu tipi,  bet tā nav "tuva" valoda.

Labots - MarisO
Link to comment
Share on other sites

Raimonds1

Es tikai mācos to valodu un savā veidā gribu vispirms izprast valodas veidotaju mērķi un risināmo  problēmu un tikai PĒC TAM  iemācīties, kā tieši to dara.

 

Man ir kaut kāda nojausma, ka šādā pieejā kaut kas ir. Pie tam man šajā tēmā ir nezināšanas priekšrocības, proti, es neko daudz nejēdzu par C++.

 

Tas, ko es pagaidām esmu uztvēris, ka džekiem bija sapratne, ka kaut kādus skaitļus un simbolus vadīs  no klaviatūras un viņi izdomāja, ka nevar tā gluži atļaut vadīt jebko, bet vajag definēt, ko tad dārgais jūzeris un jaunais programmetajs vadīs - abolu skaitu vai algas procentus vai rēķinās kosmiskās orbītas.

 

Tad nu viņi izveidoja gatavas programmas, kas rēķina gan tādos apjomos, gan daudz lielākos un, lai tās izsauktu darboties, piemēroja visādas matemātikas bibliotēkas un ievadāmo skaitļu nosaukumus.

 

Viņiem bija uzstādījums un problēma, viņi to risināja tā un caur to es saprastu, kāpēc.

Link to comment
Share on other sites

Mezavecis

Kāpēc mācies to valodu? Varbūt tomēr ieguldīt laiku zināšanās, kas dod lielāku pievienoto vērtību.

 

Vienmēr būs kompromiss starp kvalitāti un kvantitāti. Viss maksā naudu, tajā skaitā datoru resursi un tāpēc plānojot ir jāvadās pēc tā, lai šos resursus efektīvā veidā optimizētu. Optimizēt, lai optimizētu, ir bezjēdzīga darbība.

 

 

Detalizētu aprakstu par datu tipiem var izlasīt neskaitāmās grāmatās un nav nepieciešams atgremot sen zināmas lietas.

Labots - Mezavecis
Link to comment
Share on other sites

Stroustrups izdomāja, ka C valodai vajag objektus.

Tur bija tā problēma,  no kuras radās C++.

Link to comment
Share on other sites

Raimonds1

Patiesībā tēmas nosaukumu varētu paplašināt uz - Ko vajadzēja atrisināt C++ veidotājiem, kā viņi to izdarīja un kas ar to tika panākts.

 

Man nav jāzin šī valoda perfekti, gan jau kādu dažu gadu laikā pašus pamatus iemācīšos, bet tas nenozīmē, ka es nesapratīšu tās pielietojumu, iespējas un ko pasūtīt tiem, kas to prot.


"Stroustrups izdomāja, ka C valodai vajag objektus."

 

Jo bez objektiem nevarēja izdarīt ko?

 

C un Paskaāls orientējas uz procesiem.

 

es saprotu, ka te ir skaidrojums  https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp3_OOP.html

Link to comment
Share on other sites

AndrisBB

Datu tipiem ar valodas tuvumu dzelžiem sakars mazs. Gandrīz visas valodas(kompilējamas un interpretējamas) atbalsta dažādus datu tipus, tanī pašā laika var būt valoda, kura neko vairāk par 8 bitu unsigned integer neatbalsta, jo nevajag. Piemēram es tagad stādāju pie MIPS arhitektūrai līdzīga CPU, kur floating point operācijas nebus atbalstītas.

 

Te visdrīzāk jāsāk studēt no otra gala, kā skaitļi tiek attēloti binārajā formā, kā tiek saskaitīti, reizināti vai dalīti un tad iespējams nāks apgaismība par datu tipiem un to lielumiem.

Pēmēram kā izrēķināt cik ir 2345678 - 345656787 binārā formā.

Link to comment
Share on other sites

Mezavecis

Diez vai būs lietderīgi, ko valodas veidotājiem vajadzēja izdarīt. Ir tricienurbis (valoda) un tālāk, kuru lieto strādnieks (programmētājs)  un urbj sienās tur, kur pasūtītājs liek.  Lai saprastu, kur un kādus caurumus un kādā veidā jāurbj sienās, nav vajadzīgi urbja rasējumi.  

  • Patīk 1
Link to comment
Share on other sites

nevertell

 

 

Ja rodas jautājumi par resursiem priekš mūsdienu sistēmām, kas izpilda miljardiem operāciju sekundē, tad pilnīgi noteikti nav runa par zemā līmeņa risināmu,
 

Tā nu gluži ar nav.

Link to comment
Share on other sites

AndrisBB
Jo bez objektiem nevarēja izdarīt ko?

Bez objektiem var izdarīt to pašu ko ar.

Programēšna manuprāt pa lielam ir problēmas risināšna sadalot to mazākās problēmās. Pastāv dažādi veidi kā risināt un dalīt (ar ārmuru vai cirvi,  objektorientēti vai funkcionāli). Uz datiem orientētas problēmas iespējams risināt ir ērtāk objektorientēti

Labots - AndrisBB
Link to comment
Share on other sites

Uz datiem orientētas problēmas iespējams risināt ir ērtāk objektorientēti

 

 

Labāk tomēr funkcionāli.    

 

Iekš OOP datus piesaista kodam un "paslēpj" (klasēs),  kas nav laba ideja.    Tas datiem par labu nenāk  :-)

 

Es vairs nekodēju javā,  kopš sapratu, ka OOP is slikta pieeja programmēšanai. 

Labots - MarisO
Link to comment
Share on other sites

Ja sākotnēji runā par Paskal un C, tad gluži vienalga, kāt mainīgo sauc int, vai integer, float vai real, tuvību dzelžiem (ne no optimizācijas viedokļa) var redzēt tad, kad izrādās- olimpiādes uzdevuma risināšanā ir parocīgi integeru masīvu veidot no elementiem, kuri sākas ar -10to, beidzas ar 90to, (Paskāls tā atļauj, kaut gan kompilators pārstrādās no nulltā, jo negatīvs ofset ir risks iziet ārā no atmiņas gabala, kurš izdalīts masīvam), C godīgi informē, ka jāsāk ar nullto. Ja programmētājs ko adresācijā salaidīs grīstē, nāks ārā visādi brīnumi. Ja ar tuvumu dzelžiem saprot optimizāciju, tad godīgi sakot, jaunāks kompilators jaunākos dzelžos dos labākus rezultātus (ātrdarbību tai skaitā), bet tā kā jautājums patiesībā ir uzstādīts aplam (Paskal pret C++), jāteic, ka abas pieejas- funkcionāli vai objektorientēti der, katra savā veidā un vietā.

Link to comment
Share on other sites

HIGH-Zen

kā konkrēti izpaužas C++ valodas tuvums "dzelžiem"

 

Dators saprot tikai un vienīgi mašīnkodu. Asemblers ir tuvākā valoda mašīnkodam.

C++ un vēl jo vairāk C tuvums dzelžiem izpaužas tā, ka pieredzējis programmētājs zin kādu mašīnkodu (kā tas izskatīsies asemblerā) uzģenerēs kompilieris un kā tas darbosies (ko darīs procesors).

 

Asemblers ir vēl tuvāks dzelžiem, ar to var piemēram izsaukt funkciju kādā dll, kuru tā nemaz neeksportē. T.i. ko tu pateiksi dzelžiem darīt, to tie arī darīs.

 

int, float, double, char, bool tas viss ir abstrakcija, kas tiek pārvērsta mašīnkodā, procesoram tie ir tikai vieninieki un nullītes. Asemblerā mierīgi var norādīt procesoram, ka šajā adresē tagad ir char, lai lasa to, tas nekas, ka tur ir float.

 

 

Delphi/FPC arī ģenerē mašīnkodu, bet jau daudz labāku, jo ir papildus kods visādām pārbaudēm (range checking, reference counted strings) tā, ka ir mazāk jābaidās uzkāpt uz grābekļiem, bet kāds mašīnkods tiek ģenerēts nu jau ir nedaudz grūtāk saprast.

 

 

Interpretējamās valodas kā Java, Python, .NET ģenerē baitkodu, kuru tālāk izpilda virtuālā mašīna (kurā savukārt izpildās mašīnkods). Ko konkrēti dara procesors programmas darbības laikā, to nezin neviens velns, ja vien nav izpētījis kā tā virtuālā mašīna darbojas un ko tā dara, JIT kompilieri ieskaitot. Tāpēc tādas valodas ir "tālu no dzelžiem".

  • Patīk 1
Link to comment
Share on other sites

Raimonds1

 

 

int, float, double, char, bool tas viss ir abstrakcija, kas tiek pārvērsta mašīnkodā, procesoram tie ir tikai vieninieki un nullītes. Asemblerā mierīgi var norādīt procesoram, ka šajā adresē tagad ir char, lai lasa to, tas nekas, ka tur ir float.

 

pēc analoģijas - kur vēl varēja būt, bet nav vienkāršais risinājums - nosaukt visus skaitļus par number un basta. Raksti ko gribi un mašīna ar apjomīgu programmu, kas var izrēķināt kosmiskās orbītas, skaita ābolus 2. klases uzdevumā.

 

 

 

Negribi palasīties Wikipēdiju? Tur viss par vēsturi un ideoloģiju smuki uzrakstīts.

 

Vēsture ir vēsture, bet ideju attīstība, problēmas un to risinājumi attīstībā pirms 10-20-30 gadiem un tagad ir cita lieta. 

Link to comment
Share on other sites

Pag, nu, Tu jautā - "kāpēc tā valoda ir tāda, kāpēc viņu izvēlējās tieši tā un ne citādi taisīt?" Nu, tā jau tieši ir vēsture, kas gan vēl cits? Skaties sadaļu par pašiem pirmsākumiem. :D Plus, wikipēdijā jau ir arī ne tikai vēsture:

Philosophy

Throughout C++'s life, its development and evolution has been informally governed by a set of rules that its evolution should follow:

  • It must be driven by actual problems and its features should be useful immediately in real world programs.
  • Every feature should be implementable (with a reasonably obvious way to do so).
  • Programmers should be free to pick their own programming style, and that style should be fully supported by C++.
  • Allowing a useful feature is more important than preventing every possible misuse of C++.
  • It should provide facilities for organising programs into well-defined separate parts, and provide facilities for combining separately developed parts.
  • No implicit violations of the type system (but allow explicit violations; that is, those explicitly requested by the programmer).
  • User-created types need to have the same support and performance as built-in types.
  • Unused features should not negatively impact created executables (e.g. in lower performance).
  • There should be no language beneath C++ (except assembly language).
  • C++ should work alongside other existing programming languages, rather than fostering its own separate and incompatible programming environment.
  • If the programmer's intent is unknown, allow the programmer to specify it by providing manual control.
Labots - Vilx-
  • Patīk 1
Link to comment
Share on other sites

Raimonds1

 

 

Es vairs nekodēju javā,  kopš sapratu, ka OOP is slikta pieeja programmēšanai. 
 

 

https://www3.ntu.edu.sg/home/ehchua/programming/cpp/cp3_OOP.html

 

dēļ šitā?

  1. The basic unit of OOP is a class, which encapsulates both the static attributes and dynamic behaviors within a "box", and specifies the public interface for using these boxes. Since the class is well-encapsulated (compared with the function), it is easier to reuse these classes. In other words, OOP combines the data structures and algorithms of a software entity inside the same box.
  2. OOP languages permit higher level of abstraction for solving real-life problems. The traditional procedural language (such as C and Pascal) forces you to think in terms of the structure of the computer (e.g. memory bits and bytes, array, decision, loop) rather than thinking in terms of the problem you are trying to solve. The OOP languages (such as Java, C++, C#) let you think in the problem space, and use software objects to represent and abstract entities of the problem space to solve the problem.

Kas notiek, kad gatava programma tiek piemērota 32 vai 64 bitu procesoram. Vai pat 8 vai 16 bitu procesoram vai divkodolu iekārtai - kā tad darbojas visi procesi salīdzinājumā? Atšķiriba ir tikai soļu skaitā, kas katram procesoram jāveic, lai izpilditu darbību, vai atšķiras arī mainigo glabāšanas un piekļuves veids?

 

Piemēram, kaut kādi dati ir pusbaitos. 

Link to comment
Share on other sites

AndrisBB

Te ir bezgalīgi daudz grāmatu par par tēmu Amazon, izlasi kaut vienu un vairāk vai mazāk būs skaidrs.

Precizāk pietiks izlasīt kādas 2 nodaļas, lai saprastu kā processors izpilda komandas, lasaraksta atmiņu, kā kods tiek kompilēts utt

Labots - AndrisBB
Link to comment
Share on other sites

@@HIGH-Zen - Virziens pareizs, bet samērā neprecīzi. :) Mēģināšu salikt punktus uz "i":

 

Ir taisnība, ka asembleris ir "tuvākā valoda dzelžiem", lai arī asembleris vispār ir tādā ļoti īpašā statusā. Ir tā, ka procesors spēj izpildīt tikai binārus mašīnkodus. T.i, konkrētas baitu kombinācijas veic konkrētas operācijas procesorā. Dažādām procesoru arhitektūrām (x86, ARM, PIC, PowerPC, IA-64, GPU, utml) šie mašīnkodi ir dažādi, un eksistē vēl visādas atšķirības starp pieejamajām operācijām. "Asembleris" ir vienkārši šo mašīnkodu cilvēcīgais pieraksts, lai tos ir vieglāk lasīt. Viena operācija asemblerī tulkojas par vienu mašīnkodu (kompilators sanāk diezgan vienkāršs :)) Tas arī nozīmē, ka dažādām CPU arhitektūrām, asembleris būtiski atšķiras. Tāpat ir gadījies, ka divi cilvēki uzraksta asemblera kompilatorus vienam un tam pašam procesoram, bet izvēlas lietas apzīmēt dažādi - un tas viss tik un tā vēl ir "asembleris".

 

Int, float un char nav īsti abstrakcijas. Modernos CPU tiešām ir instrukcijas, kuras strādā ar šādām datu vienībām. Abstrakcija ir masīvi, objekti, stringi. Bet primitīvie datu tipi (vismaz C/C++ valodās) atbilst tādiem datu tipiem, kurus saprot CPU. Tas atvieglo kompilatora darbu un dod lielāku varu programmētājam.

 

Java un .NET nav intepretējamas valodas. Interpretējama valoda ir tāda, kur nav nekādi baitkodi vai mašīnkodi, bet source kods tiek parsēts un izpildīts vienlaicīgi. Java/.NET vispirms kodu sakompilē par baitkodiem, bet pēc tam šos baitkodus izpildes brīdī pārkompilē par mašīnkodiem. Procesors izpilda jau gatavus mašīnkodus; baitkods netiek interpretēts.

  • Patīk 2
Link to comment
Share on other sites

AndrisBB
Viena operācija asemblerī tulkojas par vienu mašīnkodu

Arī ne vienmēr, jo bieži vien Assamblerī ir visādas "pseido-instrukcijas" kurām nav atbilstoša mašinkoda instrukcija. Tad tā Assamblera instrukcija atbilst vairākām mašinkoda instrukcijām

Labots - AndrisBB
Link to comment
Share on other sites

Raimonds1
(labots)
Te ir bezgalīgi daudz grāmatu par par tēmu Amazon, izlasi kaut vienu un vairāk vai mazāk būs skaidrs.

 

Tas viss ir forši, bet te par to pašu var diskutēt, pie tam latviski. 

------------------

 

Es saprotu, ka Jūs kā praktiski strādājošus programmētājus, vairāk interesē efektivitāte, ātrums, programmēšanas problēmu maksimāli viekāršs, maz laikietilpīgs un lēts risinājums.

 

Mana interese ir nedaudz cita - programmēšanas apmācības sākuma procesi, saprašana, nevis tikai gatavu darbības veidu iemācīšanas - tipa, vajag izdarīt to, ņem to gatavo bibliotēku un iekļauj savā programmā. Protams, tā kā es daudz ko nezinu, būs zināms haotiskums, nezināšana un visādi prasti jautājumi.

Labots - Raimonds1
Link to comment
Share on other sites

AndrisBB

 

 

Tas viss ir forši, bet te par to pašu var diskutēt, pie tam latviski.

Tas informācijas apjoms ir tik liels ka te forumā tas nav aprunājams no A - Z. Daudz efektīvāk ir izlasīīt grāmatā, kurā viss ir loģiski sakārtots no pamatiem līdz komplicētākam lietām un tad jautāt to kas nav skaidrs. Ganjau arī latviski ir kāda grāmata.

  • Patīk 2
Link to comment
Share on other sites

Ja Tevi interesē mācīties, tad īpaši lielas atšķirības nebūs, ar kuru valodu sāksi. Katram, protams, mīļāka ir sava valoda, taču fakts ir tāds, ka ar visām viņām cilvēki ir iemācījušies programmēt.

 

Noteikti arī aplūko vairākas valodas. Neviena valoda nav perfekta - citādi jau jaunas valodas vairs nerastos. Taču katrā valodā ir kādas interesantas idejas, ar kurām vari bagātināties.

Labots - Vilx-
Link to comment
Share on other sites

Mezavecis

Apgūšanas pieeja ir galīgi nepareiza. Tas būtu tas pats, kas apgūt būvniecības pamatus analizējot debesskrāpi. Gribi pamatus, sāc ar vienkāršu sistēmu. Cita pieeja gandrīz vienmēr noved pie aplamas izpratnes, kura noteikti nedraudzēsies ar programmētājiem vispārzināmām lietām.

 

Vajag izlasīt grāmatu, lai vispirms orientētos terminos, nevis jautāt cilvēkiem, ko dara autiņam stūre, kā viņu pareizi sauc un kādas funkcijas veic. Nu tas tā analoģijās, lai saprastu, kur rodas kļūda komunikācijā. 

  • Patīk 1
Link to comment
Share on other sites

HIGH-Zen

 

 

nosaukt visus skaitļus par number un basta.

Tev vajag drusku padarboties asemblerī, lai saprastu, ka procesora komandas ir tādas, kādas tās ir, un noteiktā baitu daudzumā skaitļus (veselus, ar zīmi un bez, ar decimāldaļām) binārajā sistēmā var izteikt tā kā var. Nemaz nerunājot par kompleksajiem skaitļiem un daļskaitļiem.
Tā ka visus skaitļus nosaukt vienkārši par number nesanāks.

 

 

 

bet samērā neprecīzi

Es teiktu, ka diezgan precīzi. Topikstartera jautājums nebija par asembleri, tur nav nepieciešams izvērsties un apspriest atšķirības starp i368 un i686.

 

 

 

Abstrakcija ir masīvi

Nu tad padomā - tips int ir bitu masīvs vai nav?

 

 

 

baitkods netiek interpretēts.

Beidz ākstīties.

Link to comment
Share on other sites

Nu tad padomā - tips int ir bitu masīvs vai nav?

Nav, jo nav iespējams adresēt un strādāt ar individuāliem bitiem (CPU līmenī). Taču, vispār, tas ir atkarīgs no tā, kā Tu definē "masīvu". Man aizdomas, ka citādāk, nekā es.

 

Beidz ākstīties.

No Tava linka:

 

The terms interpreted language and compiled language are not well defined because, in theory, any programming language can be either interpreted or compiled.

 

...

 

An interpreted language is a programming language for which most of its implementations execute instructions directly, without previously compiling a program into machine-language instructions. The interpreter executes the program directly, translating each statement into a sequence of one or more subroutines already compiled into machine code.

Un no linkotā raksta:

A bytecode program may be executed by parsing and directly executing the instructions, one at a time. This kind of bytecode interpreter is very portable. Some systems, called dynamic translators, or "just-in-time" (JIT) compilers, translate bytecode into machine language as necessary at runtime: this makes the virtual machine hardware-specific, but doesn't lose the portability of the bytecode itself. For example, Java and Smalltalk code is typically stored in bytecoded format, which is typically then JIT compiled to translate the bytecode to machine code before execution.

Citiem vārdiem sakot - jā, baitkodu var interpretēt, bet tas ir lēni, un mūsdienās tā reti kurš dara. Tā vietā baitkodi tiek pa veseliem gabaliem (tipiski pa veselām metodēm vai klasēm) runtaimā pārkompilēti uz mašīnkodiem, un tad procesoram tiek padoti izpildei tieši šie mašīnkodi. Nekas netiek interpretēts instrukciju-pa-instrukcijai.

 

Bet, protams, šīs definīcijas ir pietiekoši šķidras, lai tur varētu sākt skaldīt matus.

Labots - Vilx-
Link to comment
Share on other sites

HIGH-Zen

 

 

Nav, jo nav iespējams adresēt un strādāt ar individuāliem bitiem (CPU līmenī)

Pat ja nebūtu iespējams strādāt, tas tāpat ir masīvs. Un strādāt ir iespējams arī CPU līmenī - Bitwise operations.

 

Bez virtuālās mašīnas nekāds Java vai .Net mašīnkods nedarbojas, ir vajadzīgs interpretators baitkodam jeb virtuālā mašīna, tas, ka tiek izmantots JIT kompilieris neko tur nemaina.

 

Tai pat linkā

Java (is compiled into Java bytecode to be interpreted by JVM)

 

Link to comment
Share on other sites

AndrisBB

 

 

Pat ja nebūtu iespējams strādāt, tas tāpat ir masīvs. Un strādāt ir iespējams arī CPU līmenī - Bitwise operations.

Bitwise operācijas jau nevar izmainīt tikai vienu bitu, tiek apstrādāts viss baits (vai 16/32 biti atkarībā no arhitektūras), kurš tiek izlaists cauri ALU, kurā izpildās vajadzīgā loģiskā operācija (shift/rotation/or/and un citas).

ARM atbalsta tādu lietu kā Bit-banding, bet tas arī ir stipri ierobežots

http://spin.atomicobject.com/2013/02/08/bit-banding/

Link to comment
Share on other sites

HIGH-Zen

Ar bitwise AND var izmainīt vienu bitu, tas nekas, ka tiek apstrādāds viss baits. Baits fiziski ir bitu masīvs.

Link to comment
Share on other sites

AndrisBB

Tad ir jādefinē kas ir masīvs.

Tu piemēram vari pateikt CPU vienā instrukcijā saskaitīt pirmo integer masīva elementu ar otro un saglabāt rezultātu trešajā, bet tu nevari saskaitit pirmo bitu ar otro un saglabāt trešajā, tātad CPU nevar veikt tiešas operācijas bitu līmenī. To var izdarī vairākos etapos, bet ne  vienā operācijā

Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...