-
Data: 2019-04-21 14:52:59
Temat: uwagi o stosie (na argumenty i zm. lokalne) w c jako przezytku/przestarzalosci
Od: fir <p...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]kopia moich uwag jakie napisalem na clc, sa one raczej dosyc ciekawe (moze
powimnienem to raczej zapostowac na pclc ale w sumie dotyczy to tez i innych jezykow
nie tylko c)
i wrote on it years before, but recently i
seen even to be stronger in this position:
(so i think what i say here ios not total repeat, i slightly upgraded my view):
roughly speaking stack in c today seem nearly totaly obsolete and useless
i mean c variables (arguments and locals) rather shouldnt be placed on stack, it
rather should be all static (some eventually optimised away to register)
it seem to me that making a (locals and arguments) stack in old c
was maybe for 2 reasons
1) some mistake that people was thinking that recursion calls was much more common
and important as it really is (in reality it is roughly zero, and it is posible with
not much reall loss to turn it to zero,
[hovever im not saing to get rid of auto variables totally, i think it would be good
to make them as a some option/extension
i mean probably only some variables explicitely marked as 'auto' should be realized
by stack (as i said back then it should be most probably different stack that this
one for call-ret and also more stack eventually should be avaliable by keywiord like
auto(1) [stack 1] auto(7)
stack number 7 etc] maybe that stack should ba also declared explicitely in c program
whith its size etc (this way such stack would be like local array but with some
additional c compiler support there][that was digression]
in fact most normal programs i wrote dont use recursive calls (in fact besides some
experimen no one uses it)
2) some idea that occured to me was that in old c maybe stack was also used to
minimalise ram usage when it was really tiny like i dont know you got 256 byte long
stack or someting, maybe it was like that that when you got bog code that has in
summary few hundreds of local variables if thay would be static they in summary
(maybe, as i maybe not seen it toitally clearly) could consume more ram then when in
stack version code would reuse that smaller minimal stack ram for them creating them
and deleting at runtime (but this is hipothesis)
if so this is rather no longer needed ;c
(i mean auto as i said slitt culd be avaliable, if i dont know some people would like
to write some large programs that use only few bytes of ram, if thats possible)
it also seem for me that I) from efficiency reasons the static wersion would be
faster II) from overal simplicity static version would be simpler (simpler to debug,
simpler to reason, also simpler to make some enhancemsnts and so on)
Overally as i said stack is obsolete to me
(i mean that stack as today, not the pure call-ret stack which should obviously stay)
///
note btw some side note
when i was back then talking on moing those variables eventually to other stack then
this call-ret one (name it "stack zero") it sounded a bit like theory (at least to
me) as it seemd that stack is something that partially needs os support etc.. now i
see it stopped sounding like theory as when i wrote a bisics of compiler i see it can
fully be done (by compiler side) you simply in compiled code only put call-ret
adresses on present stack, and if you want to inplement thiose auto(n) stacks just
implement them (on arrays in .bss) you event dont need to limit yourself as to
numbers and sizes, also you even may make them relocable, resizable if need (some one
may make resizable or shrinkable, some not for efficency etc)
more funy whan i wrote thsi compiler i felt like lazy of non implementic this locals
on tack (al teast not firstly).. possibly from my lazines i may really no
implement it att all, and start to implement it right way (this is as statics)
(not that im in a mood to implement it, recently i still feel exhausted)
Następne wpisy z tego wątku
- 21.04.19 20:40 t-1
- 23.04.19 13:50 g...@g...com
- 23.04.19 18:07 fir
Najnowsze wątki z tej grupy
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-12-16 W telefonie brak szufladki na drugą kartę SIM
- 2024-12-16 Szukam monitora HDMI ok. 4"
- 2024-12-16 Poznań => Key Account Manager <=
- 2024-12-16 Akwarium w aucie
- 2024-12-16 Warszawa => Account Manager - Usługi rekrutacyjne <=
- 2024-12-16 Warszawa => Expert Recruiter 360 <=
- 2024-12-16 Gdańsk => System Architect (background deweloperski w Java) <=
- 2024-12-16 Warszawa => Key Account Manager <=
- 2024-12-16 Warszawa => Spedytor Międzynarodowy <=
- 2024-12-16 Białystok => Analityk w dziale Trade Development (doświadczenie z Po
- 2024-12-16 Warszawa => Programista Microsoft Dynamics 365 Business Central <=
- 2024-12-16 Wrocław => Konsultant wdrożeniowy Comarch XL/Optima (Księgowość i
- 2024-12-16 Szczecin => Key Account Manager (ERP) <=
- 2024-12-16 Lublin => Inżynier Serwisu Sprzętu Medycznego <=
- 2024-12-16 Gdańsk => Specjalista ds. Sprzedaży <=