eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › uwagi o stosie (na argumenty i zm. lokalne) w c jako przezytku/przestarzalosci
Ilość wypowiedzi w tym wątku: 4

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

    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)


  • 2. Data: 2019-04-21 20:40:16
    Temat: Re: uwagi o stosie (na argumenty i zm. lokalne) w c jako przezytku/przestarzalosci
    Od: t-1 <t...@d...pl>

    W dniu 2019-04-21 o 14:52, fir pisze:
    > 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)

    Być może, to ciekawe, skoro sam tak twierdzisz.
    Ale jak to można rozszerzyć na stos w składzie węgla?


  • 3. Data: 2019-04-23 13:50:39
    Temat: Re: uwagi o stosie (na argumenty i zm. lokalne) w c jako przezytku/przestarzalosci
    Od: g...@g...com

    W dniu niedziela, 21 kwietnia 2019 14:53:00 UTC+2 użytkownik fir napisał:
    > 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)

    Z tego co się orientuję, większość parserów języków ogólnego przeznaczenia stosuje
    rekurencję.

    > 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

    Dlaczego?
    W moim odczuciu zaletą stosowania zmiennych na stosie jest to, że jest to przyjazne
    dla cache'u.
    Jeżeli każda funkcja, którą wywołujesz, musi się z konieczności odnosić do jakiegoś
    losowego miejsca w pamięci, to taka strategia będzie dużo mniej przyjazna dla
    cache'u.
    Nie wydaje mi się też, żeby był jakikolwiek powód, dla którego ustatycznienie
    wszystkich zmiennych lokalnych miałoby być szybsze (przynajmniej na intelu dodawanie
    offsetów do adresów zmiennych jest wykonywane przez dekoder instrukcji)

    No ale to oczywiście jest jakaś hipoteza, i można ją zweryfikować odpowiednimi
    pomiarami.

    II) from overal simplicity static version would be simpler (simpler to debug, simpler
    to reason, also simpler to make some enhancemsnts and so on)

    Czyli zasadniczo proponujesz model stosowany we wczesnych wersjach języka
    BASIC.

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

    AFAIK na ARMach konwencja wywołań funkcji jest sensowniejsza, niż na Intelu, bo adres
    powrotu jest przechowywany w rejestrze ("Link Register"), a nie na stosie, i jeżeli
    funkcja wołająca inną funkcję robi coś z jej wynikiem, to to ona jest odpowiedzialna
    za to, żeby ewentualnie zawartość tego rejestru zapisać, zmienić i odtworzyć.

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


  • 4. Data: 2019-04-23 18:07:47
    Temat: Re: uwagi o stosie (na argumenty i zm. lokalne) w c jako przezytku/przestarzalosci
    Od: fir <p...@g...com>

    W dniu wtorek, 23 kwietnia 2019 13:50:41 UTC+2 użytkownik g...@g...com napisał:
    > W dniu niedziela, 21 kwietnia 2019 14:53:00 UTC+2 użytkownik fir napisał:
    > > 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)
    >
    > Z tego co się orientuję, większość parserów języków ogólnego przeznaczenia stosuje
    rekurencję.
    >
    > > 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
    >
    > Dlaczego?
    > W moim odczuciu zaletą stosowania zmiennych na stosie jest to, że jest to przyjazne
    dla cache'u.
    > Jeżeli każda funkcja, którą wywołujesz, musi się z konieczności odnosić do jakiegoś
    losowego miejsca w pamięci, to taka strategia będzie dużo mniej przyjazna dla
    cache'u.
    > Nie wydaje mi się też, żeby był jakikolwiek powód, dla którego ustatycznienie
    wszystkich zmiennych lokalnych miałoby być szybsze (przynajmniej na intelu dodawanie
    offsetów do adresów zmiennych jest wykonywane przez dekoder instrukcji)
    >
    > No ale to oczywiście jest jakaś hipoteza, i można ją zweryfikować odpowiednimi
    pomiarami.
    >
    > II) from overal simplicity static version would be simpler (simpler to debug,
    simpler to reason, also simpler to make some enhancemsnts and so on)
    >
    > Czyli zasadniczo proponujesz model stosowany we wczesnych wersjach języka
    > BASIC.
    >
    > > 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)
    >
    > AFAIK na ARMach konwencja wywołań funkcji jest sensowniejsza, niż na Intelu, bo
    adres powrotu jest przechowywany w rejestrze ("Link Register"), a nie na stosie, i
    jeżeli funkcja wołająca inną funkcję robi coś z jej wynikiem, to to ona jest
    odpowiedzialna za to, żeby ewentualnie zawartość tego rejestru zapisać, zmienić i
    odtworzyć.
    >
    > > 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)

    co do dtacku to nie wydaje mi sie by byl przyjazniejszy dla cache, chyba nawet
    odwrotnie - stack dziala torche jak wieczme memcopy, w kolko robi kopiowanie, kazdy
    call wpisuje (memcopy) argumenty na stos - w wersji ze statycznymi przynajmniej te
    wartosci sa ciagle w tych samych miejscach co wydaje mi sie zaleta, zreszta kompiler
    moglby je ulozyc jak chce 9przynajmniej jakby sie uparl, bo mz powinny byc raczej
    ulozone kolejno logocznie jak w funkcji to by bylo prostsze)

    z tym cachem to ogolnie pieprzenie, kiedys chyab opowiadalem jak robilem testy
    okazalo sie ze w moich programach po prostu 'pokrycie' cache wydaje sie
    idealne, tj jak liczyc predkosc kodu to byla ona raczej idealna tak jakby wszystko
    bylo w cache, wiec nie ma co o tym gadac, z tych obserwacji wynika mz ze arczej ci co
    gadaja o tym nietrafieniu to nei wiedza o czym mowia alebo pisza wyjatkowo rozbabrane
    programy


    ogolnei zachecam do pogadanie ale moze w watku na comp.lang.c bo tam wiecej ludzi

strony : [ 1 ]



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: