Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:

>> Ja nawet w czasach Odry pojecia stosu nie znalem (nie liczac sortowania
>> stogowego;)
>
> Musiałeś znać. Inaczej miałeś klopoty przy implementacji byle czego. RAM i bębny
nie są z gumy.
> Wtedy nie były i dzisiaj ich odpowiedniki nie są.

No nie znalem.
RAM byl z gumy (os go wirtualizowal)

>
>> a co dopiero o jakims" grzebaniu". Naprawde przestan bzdurzyc o rzeczach
>> ktorych nie dotknales i nie masz o nich zielonego pojecia. Tworzysz
>> jakies chore mity.
>> Pamiec rezerwolo sie tak:
>>
>> begin
>> integer array a[lbound_expression: ubound_expression, ...];
>>
>> end
>>
>> wsio. To kompilator decydowal gdzie/jak ja skladowac badz "zwirtualizowac".
>
> Nie da się tak pisać bez kompromisow. Jęsli system to wyrzucił na bęben z powodu
braku ram to
> jestes w dupie z wydajnością. Magiczna cecha Odry ktora powodowała że pamięc była z
gumy jest
> nieprawdziwa. Tylko się nie rozpłacz.

1. Jaki znow beben ? :)
2. Owszem, wydajnosc "siadala", ale program dalej dzialal, a nie
"zamazywal stosem sie/dane" czy inne rzeczy znane z C/C++/PC-ta :)

>>> Zastanawianie się jak 100k danych wsadzić w 32k nie rozwiązuje sie
>>> tylko dlatego że masz mainframe.
>> A zastanawiaj sie dalej.
>> Za mnie robil to kompilator (ale nie niskopoziomowego C++:)
>
> Naprawde nie widzisz problemu że twoje dane lądują na urzadzeniu które jest setki
razy wolniejsze
> bo się nie mieści w ram?

To byla sprawa systemu , co nie znaczy ze nie bylo tego swiadomosci
i nie projektowalo sie tak aby jak najmnej trafialy, a niektore algorytmy byly
az do tego stworzone (np. taki simplex z generacja kolum przy np. metodach
rozkroju, czy metody podzialu i ograniczen, itp itd), aby trafialy "madrze".
No i wlasnie tu trzeba bylo i umiec dobrze to so napisalli/stosowali
"starsi w wierze informatycznej - szacun dla nich" i glowkowac jeszcze nad
ulepszeniem czy wlasnymi pomyslami/rozwiazanaimi.
Skutek bywal taki ze na tej przyslowiowej badziewiastej Odrze z mala pamiecia
liczono np.optymalizacje planu remontow piecow kilku hut slaskich
(a koszt wylaczenia pieca to nie bylo byle co).

> PS. Każdy duzy współczesny OS potrafi to samo, czyli dac pełna przestrzeń adresową
dla procesu
> magicznie swapując ją w tle. Gdzie tu jakaś zaleta mainframe?

1. wirtualizacja calych systemow operacyjncych (np VM na IMB360/370)
OK. Nareszcie sa VMWare i VirtualBox, ale troche to twralo :)
2. hibernate/restore dowolnego joba/zadania/programu.
Tego nie masz na PC nawet dzis.
(mowie tylko o maiframes starych - wspolczesnych nie znam)
3. fault tolerant

> Obecnie niczym. Procesy na x86 w win i lin są separowane w sposób doskonały.

"Teraz" "obecnie", "od pieciu lat". Zgadza sie, ale Odra to miala w latach
siedemdziesiatych i miala od poczatku (tak jak zaprojektowano).
Troche szacunku do tamtej mysli informatycznej.
PC-ty dorobily sie tego po wielu latach (ok 15stu od zaistnienia), a wczesniej
"krolowal" slawetny tryb "real mode" i klopoty z A20 (enhanced, extended
memory,high memory i rozne inne prowizorki + slawetne modele pamieci
procesora x86).

AK


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus