On 2015-09-12 17:41, AK wrote:
>>> Czlowieku ! Odra 1300 (zwlaszcza 1305) to _mainframe_. !
>> No i co z tego skoro w zasobach sprzetowych przypomina wiekszośc
>> współczesnych uC?
> To z tego, ze na tych "ograniczonych zespolach sprzetowych"
> dzialaly calkiem spore systemy (w tym np. teletransmisyjne i to grubo przed
> doba internetu). No ale wtedy nie bylo takich fachowcow jak ty wiec nie
> wiedzili(smy:) ze sie nie da ;))

KTO POWIEDZIAŁ ŻĘ SIĘ CZEWGOŚ NIE DA? Znowu urojenia? Współczesne uC
mają takie same zasoby sprzetowe jak Odry. Wspóczesne uC mają systemy
operacyjne z wieloma cechami z dużych systemów. To podobne środowiska,
wiele uC jest w stanie pociągnąć gigabajty ram i gigahz.

>>> Nie ma _nic wspolnego_ z zadnym programowaniem niskopoziomowym.
>> Programowanie niskopoziomowe to między innymi dbanie o allokowanie
>> pamięci w sposób kontrolowany,
> I niby takie "dlubanie" to cecha Odry ?

Każdego systemu który musi być pisany kompromisowo ze względu na
ograniczone zasoby.

> Chlopie, napraewde bzdurzysz.
> 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ą.

> 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.

>> 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?

Masz kompromis:
a) albo to 100k wrzucisz w "coś" i bedzie dzialać setki razy mniej wydajnie
albo
b) zmniejszysz nazwiska do 10 znakow i upchniesz w 32k

Tak czy inaczej kompromis. A wątek ten jest o tym wlaśnie: gro systemów
uzywanych w administracji publicznej posiada tak kiepskie cechy
(wydajnośc, skalowalnośc itd) że przyczyna być może jest w "lepsze jest
wrogiem dobrego, pracujemy dalej na IBM360".

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?

>>> Ba! Standardowo nie bylo tak w ogole dostepu do niskopoziomowych rzeczy.
>> No i? Głupi windows nie pozwala na dlubanie w rejestrach sprzetowych
>> inaczej niż przez driver. No i?
> Czlowieku, czy Ty wiesz czym sie rozni w pelni separowalne zadanie
> (a niekiedy i caly system operacyjny uruchamiany wirtualnie)
> od tego modelu wspolbieznosci i ochrony pamieci ktory jest znany
> z rodziny 8x86 ?

Obecnie niczym. Procesy na x86 w win i lin są separowane w sposób
doskonały. Maszyny wirtualne pracujące na x86 znamy od bardzo dawna.
Obecnie (od 5 lat przynajmniej) wszystkie procesory x86 wirtualizuja na
poziomie sprzetowym. Zakładasz że ludzie sa tak głupi że nie wiedzą jak
to działa? Ludzie tego *używają*. Wyjrzyj przez okno. Lub porzedstaw
cechy które są niezbedne do implementacji w systemach, ba jak widac
reszta świata to idioci i czegoś nie zrobili.

>>> Naprawde sobie poczytaj o GEORGE3
>> Czytałem lata temu. Taka ciekawostka. Myślę że wiele z tego obecnie
>> nie ma juz żadnego znaczenia - praktycznie wszystkie współczesne OSy
>> mają cechy bardziej użyteczne lub wręcz identyczne.
> Tak ?.
> 1. _Nic_ nie przeczytales o GEORGE3.
> 2. Nie. Wspoplczesne os-sy PCowe nie maja. Przynajmniej kilku z nich.

Jakie to istotne cechy których nie mają? Jestem (a może "jesteśmy" -
reszta znudzona tym flejmem) ciekawy.