Kezdőoldal » Számítástechnika » Programozás » Minden programozási nyelvben...

Minden programozási nyelvben átadódnak a globális változók a függvényeknek?

Figyelt kérdés
Ezt egy javascript tananyagban olvastam, hogy több memóriát fogyaszt egy globális változó, mivel át kell adni minden fvnek. Én azt hittem, hogy átadás nélkül látják őket a fvnyek.

2021. aug. 24. 10:53
1 2 3 4
 21/32 anonim ***** válasza:
27%

"Annyira, hogy már a boot eljárás közben protected módba vágja a BIOS a gépet.."


Micsoda????

Na takarodj, te buta seggfej!


A BIOS nem kapcsolja védett módba a PC processzorát te ostoba segg, mert ha így lenne, akkor valós módú oprendszert nem is tudnál futtatni rajta.

2021. aug. 24. 21:39
Hasznos számodra ez a válasz?
 22/32 anonim ***** válasza:
32%
11: Igaz amit írsz, de nincs jelentősége, mert a stack úgyis fix méretű, nem lesz több a memória sehogy.
2021. aug. 24. 22:19
Hasznos számodra ez a válasz?
 23/32 anonim ***** válasza:
49%

Akit érdekel a dolog, az ezen a linken olvashat róla, végignéztem, leellenőriztem, korrekt, fogyasztható infó:


[link]

2021. aug. 24. 22:36
Hasznos számodra ez a válasz?
 24/32 anonim ***** válasza:
88%
"Az igazi áttörés a 386-os sorozat volt, a protected móddal ". Igen ezt elismerem mert itt tényleg picit félre érthetően írtam, a 286 és a 386 protected modja közütt volt különbség, pont a memória kezelésben és a szegmentálásban. A mondat úgy "helyesebb" lett volna, hogy a 386 protected modja volt. De a lényegen nem változtat. Illetve ha figyelmesen olvasod oda is írtam: "Ez a hardver...", hogy a program hogyan használja az a hardvert független, mert már oprendszer függő. Az teljesen egy oprendszer specifikus dolog, hogy hogyan fogja kezelni a memóriát, hogyan teszi külön a programot az adattól, és mi lesz az átjárhatóság köztük (pl. segmentation fault, general protection fault és társaik). Mondjuk ez már off nagyon a kérdéshez.
2021. aug. 24. 22:38
Hasznos számodra ez a válasz?
 25/32 anonim ***** válasza:
4%

24:

"Igen ezt elismerem mert itt tényleg picit félre érthetően írtam,"


Te sajnos nem csak ott írtál, mit szépítsük, hülyeségeket. Szinte minden mondatodba bele lehet kötni.

Nem tudom, mire volt ez jó, azon túl, hogy önmagad, vagy az itt megfordulók előtt tetszelegtél és engem megpróbáltál leégetni.


Erre az oldalra azok érkeznek, akik valamit tudni szeretnének. Ez az oldal kiszolgálja az ő ebbéli igényeiket, de ha úgy teszi, hogy hülyeséget tanulnak, az nem jó, mert a te majomkodásod okán mások érdemi munkája is megkérdőjeleződik. A szolgáltatást mások később igénybe sem veszik, ha azt hallják, hogy az itt kapott válaszok nyilvánvaló hülyeségek.


Az nem tesz semmit, hogy (szerinted) hány éve volt ez igaz. Az egyetemeken a számítógép architektúrákat így tanítják, mert másképp nem is lehet. Nem lehet a PC, pontosabban az x86-os CPU szerkezeti felépítését egyből védett móddal oktatni, ezért oktatják a mai napig is a valós mód ismertetésével. Ha rákeresel egyetemi anyagokra, akkor meg fogod látni.

Egy példa: [link]


Az sem igaz, amit hablatyoltál a fordítókról, azok verzióiról.

Ez a felállás, hogy adat-, stack- és kódszegmens, így volt, így van ma is, és garantáltan így lesz húsz év múlva is. Ettől eltérni nem lehet, mert nincs is hova, meg, túl sok értelme nem is igen lenne.


Nem tudom, hogy milyen 1964-ben írt könyvet olvastál, de optimalizálni hiba nélkül lehet egyszerre space-re és time-ra is, ha amúgy van is mit. Az adott helyzet határozza meg, hogy miképpen érdemes ezt megtenni, de hogy lehet, az biztos.


A szegmentált, 64 k-s lapokra osztott címzésmód meg onnan ered, hogy az x86 megjelenése idején már kialakultak un. kvázi szabványok, a CPU-k tokozása a standard 40 DIP volt. Ebbe kellett beleszuszakolni egy olyan procit, ami a korábbi 4,16 majd 64k memória helyett mindjárt 16-szor 64k-t kezel.

Erre akkor csak ezzel az eltolásos módszerrel volt lehetőség. Ma már undorító, de akkor ez eszméletlen nagy dolog volt, hiszen nem sokkal korábban még 4 kB-ban futó BASIC interpretereket programoztak az emberek, mert ennyi memória volt a gépükben, összesen. Esetleg 8kB. Na, ehhez képest a 16-szor 64k maga volt a földi menyország.

2021. aug. 25. 02:00
Hasznos számodra ez a válasz?
 26/32 anonim ***** válasza:
33%

#5-ösnek:

4-es vagyok

kifejteném normálisan is, de inkább a további válaszokat látva offolom a témát, nem akarok ilyen ovis hülyeségekbe belemenni látva a reakciókat itt

2021. aug. 25. 06:43
Hasznos számodra ez a válasz?
 27/32 anonim ***** válasza:
83%

"A szegmentált, 64 k-s lapokra osztott címzésmód meg onnan ered, hogy az x86 megjelenése idején már kialakultak un. kvázi szabványok, a CPU-k tokozása a standard 40 DIP volt. Ebbe kellett beleszuszakolni egy olyan procit, ami a korábbi 4,16 majd 64k memória helyett mindjárt 16-szor 64k-t kezel."


És bizonyítottad a totális hozzá nem értésedet. Nézd meg a lábkiosztást. A szegmentálás nem azért kellett mert nem fértek el a 40 lábon, hanem azért mert az ALU-ba nem fért be 16bitnél több, és nem lehettt másképpen a címeket kiszámolni. A fizikai címbusz 20 bites volt.

2021. aug. 25. 09:51
Hasznos számodra ez a válasz?
 28/32 anonim ***** válasza:
6%

"hanem azért mert az ALU-ba nem fért be 16bitnél több, és nem lehettt másképpen a címeket kiszámolni. A fizikai címbusz 20 bites volt."


Az ALU a processzoron belül egy külön egység. Az végzi az (arithmetikai, logikai) műveleteket. Köze nincs a címekhez. Ahhoz az MMU-nak van köze.


Ne keverd már össze a címbuszt az adatbusszal. Az adatbusznak kelett 16 bitesnek lennie, nem a címbusznak. LEgalábbis ahhoz, amiről beszélsz (ALU).



Az 1978-ban bevezetett 8086-os család a hírnevét jórészt annak köszönheti, hogy az IBM a személyi számítógépeihez ezt a mikroprocesszort választotta. A számítógépipar fejlődésével párhuzamosan folyt a mikroprocesszor továbbfejlesztése is: megjelentek a 32 bites (80386, Pentium) és a 64 bites (Itanium) változatok. Az egyszerűbb alkalmazásokra készült a 8088-as, kívülről szemlélve nyolcbites változat.


A 16 bites regiszterek egy részénél az egyes byte-ok külön is kezelhetők. A memóriatartományt 1 Mbyte-ra tervezték (20 címvonal).



______A 20 bites címet egy 16 bites cím és egy pointer regiszter tartalmának összeadásával kapjuk._____


Ez az eljárás szegmentált memóriához vezet, és némileg bonyolítja a memória elérését, de az utasítások megfelelő kialakításával definiálták, hogy melyik

regiszterek segítségével hozható létre a teljes cím.

2021. aug. 25. 15:24
Hasznos számodra ez a válasz?
 29/32 anonim ***** válasza:
0%

Egy processzornak kell három busz.

A címbusz, amivel a memóriát címzi, az adatbusz, amin ki-be sétálgatnak az adatok és a kontroll busz. Na meg plusz két láb a tápsínnek.

Ebből 1 MB címzéséhez kell 20 címvonal. A 40 láb fele már ugrott. Ha leszámítjuk a tápsín két vezetékét és a 16 vezetékes adatbuszt, akkor mi marad a kontrollra? Két vezeték.


Ezért az x86-nál a mérnökök multiplexálták (közösítették) az adat és címbuszt, majd, mivel az adatbusz csak 16 bites volt (lévén 16 bites maga a processzor is, ugye) így a 16 bites címbuszhoz hozzácsaptak még négy bitet, némi trükkel. Így lett meg kerülő úton, körülményesen, a tényleges 20 bites fizikai cím.

2021. aug. 25. 15:39
Hasznos számodra ez a válasz?
 30/32 anonim ***** válasza:
83%

"Az ALU a processzoron belül egy külön egység. Az végzi az (arithmetikai, logikai) műveleteket. Köze nincs a címekhez. Ahhoz az MMU-nak van köze." És akkor hogyan és mivel számolja ki egy processzor pl. egy ugró utasítás cél címét pl. egy relatív jumpnál? Elárulom neked erre az ALU-t használja. Fogja a PC (program counter értékét) és hozzá adja a relatív jump értékét (pl. 500-at ha 500 byte-al kell odébb ugrani). Majd az így kapott értéket átmásolja a PC-be (nem véletlen, hogy a PC is ugyanabban a regiszter bankban van mint a többi regiszter). És itt van a probléma, mert 16 bites műveleket tud elvégezni, így a PC is csak 16 bites tud lenni, és máris bukott a 20bites címtartomány kicímzése. De ugyanez igaz bármilyen címzésnél, ahol egy regiszter értéke adja a címet (akár pl. az index regiszter is lehet ilyen, indexelt címzés esetén, vagy egy indirekt címzés esetén, ami nélkül meg egy rakás dolgot meg se lehetne csinálni a procival).

És nem 4 bitet "csaltak el" hanem az adatbusz és a címbusz van ugyanazokra a kivezetésekre multiplexálva, és így az adat és a címbusz összesen 20 vezetéket foglal el. A 8086 esetén 16 bites adatbusz és a 20 bit címbuszból 16 vezeték közös, a 8088 esetén 8 bites a külső adatbusz.


És az, hogy mi, hogyan van kivezetve, és a proci belsejében, hogyan számol az két rohadtul külön dolog. Itt a fő probléma az volt, hogy belül voltak 16 bites regiszterei, és az ALU is csak 16 bitesen tudott számolni, és nem lehetett sehogyan sem 16 bitesnél nagyobb mennyiséget leírni...

2021. aug. 25. 16:32
Hasznos számodra ez a válasz?
1 2 3 4

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!