• Re: A thought of C

    From makendo@makendo@makendo.invalid to comp.lang.c,alt.lang.asm on Wed Apr 15 21:40:36 2026
    From Newsgroup: alt.lang.asm

    The 4th difference: Local variable.
    (Assembly can theoritically do the same but I don't have impression which one support this feature.)

    If you are talking about function-local data, there are multiple ways
    to do store them in an easy-to-clean-up fashion:

    - Volatile registers, for the shortest lived data. Calling other
    functions causes them to be overwritten with the function's
    return value or irrelevant data.
    - Non-volatile registers, for data that need to persist across
    function calls. You save the contents of them before using them,
    as your caller expects the contents of these registers to be
    intact once you return.
    - The stack, for long-lived function-local data when you are out of
    non-volatile registers. You manipulate a dedicated stack pointer
    register to allocate and deallocate space for your data.
    - Immediates, and the .rodata (ELF) / .rdata (PE) section, for
    constants and tables of constants.

    The notion of local variable allows you to ignore all of these in C,
    though. Assembly having multiple ways to store local data instead of
    one can make things fairly complicated to read, write and debug.

    (forwarding to alt.lang.asm because you are comparing C with it)
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Jonathan Lamothe@jonathan@jlamothe.net to comp.lang.c,alt.lang.asm on Wed Apr 15 10:51:00 2026
    From Newsgroup: alt.lang.asm

    makendo <makendo@makendo.invalid> writes:

    The 4th difference: Local variable.
    (Assembly can theoritically do the same but I don't have impression which one
    support this feature.)

    If you are talking about function-local data, there are multiple ways
    to do store them in an easy-to-clean-up fashion:

    - Volatile registers, for the shortest lived data. Calling other
    functions causes them to be overwritten with the function's
    return value or irrelevant data.
    - Non-volatile registers, for data that need to persist across
    function calls. You save the contents of them before using them,
    as your caller expects the contents of these registers to be
    intact once you return.
    - The stack, for long-lived function-local data when you are out of
    non-volatile registers. You manipulate a dedicated stack pointer
    register to allocate and deallocate space for your data.
    - Immediates, and the .rodata (ELF) / .rdata (PE) section, for
    constants and tables of constants.

    The notion of local variable allows you to ignore all of these in C,
    though. Assembly having multiple ways to store local data instead of
    one can make things fairly complicated to read, write and debug.

    (forwarding to alt.lang.asm because you are comparing C with it)


    So what you're saying is that assembly can do anything that any other
    arbitrary language (that has to eventually compile down to the same
    machine code) can do? This should not be surprising to anyone.
    --
    Regards,
    Jonathan Lamothe
    https://jlamothe.net
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From wij@wyniijj5@gmail.com to alt.lang.asm on Thu Apr 16 01:10:36 2026
    From Newsgroup: alt.lang.asm

    On Wed, 2026-04-15 at 21:40 +0800, makendo wrote:
    The 4th difference: Local variable.
    (Assembly can theoritically do the same but I don't have impression which one
    support this feature.)

    If you are talking about function-local data, there are multiple ways
    to do store them in an easy-to-clean-up fashion:

    -a-a - Volatile registers, for the shortest lived data. Calling other -a-a-a-a functions causes them to be overwritten with the function's
    -a-a-a-a return value or irrelevant data.
    -a-a - Non-volatile registers, for data that need to persist across
    -a-a-a-a function calls. You save the contents of them before using them, -a-a-a-a as your caller expects the contents of these registers to be -a-a-a-a intact once you return.
    -a-a - The stack, for long-lived function-local data when you are out of -a-a-a-a non-volatile registers. You manipulate a dedicated stack pointer -a-a-a-a register to allocate and deallocate space for your data.
    -a-a - Immediates, and the .rodata (ELF) / .rdata (PE) section, for
    -a-a-a-a constants and tables of constants.

    The notion of local variable allows you to ignore all of these in C,
    though. Assembly having multiple ways to store local data instead of
    one can make things fairly complicated to read, write and debug.

    (forwarding to alt.lang.asm because you are comparing C with it)
    I think the local variable thing (of my trial) depends on the program model (computation model). Thanks for the info, your suggestion relates to more-a complicated stuff than I encountered (I am compiler newbie).
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?=@jmj@energokod.gda.pl to comp.lang.c,alt.lang.asm on Wed Apr 15 20:23:52 2026
    From Newsgroup: alt.lang.asm

    W dniu 15.04.2026 o-a15:40, makendo pisze:
    (forwarding to alt.lang.asm because you are comparing C with it)

    Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
    ohter asm related groups. Is this wrong aproach?
    --
    Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, EU Efc-Efc|;
    tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
    Domowa s. WWW: <https://energokod.gda.pl>;
    Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
    Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
    UWAGA:
    NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Kerr-Mudd, John@admin@127.0.0.1 to comp.lang.c,alt.lang.asm on Wed Apr 15 21:01:18 2026
    From Newsgroup: alt.lang.asm

    On Wed, 15 Apr 2026 20:23:52 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a15:40, makendo pisze:
    (forwarding to alt.lang.asm because you are comparing C with it)

    Great, but what is wrong with comp.lang.asm ? I subcribe it instead any ohter asm related groups. Is this wrong aproach?

    DYM comp.lang.asm.x86?

    comp.lang.asm is an empty header for me on eternal september's feed.

    AFAIAA there's no moderator approving posts to clax these days, so I
    don't think anything gets posted there.

    --
    Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, EU Efc-Efc|;
    tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
    Domowa s. WWW: <https://energokod.gda.pl>;
    Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>; Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
    UWAGA:
    NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

    sig is overlong, and crowded, IMHO.
    --
    Bah, and indeed Humbug.
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?=@jmj@energokod.gda.pl to comp.lang.c,alt.lang.asm on Wed Apr 15 22:40:55 2026
    From Newsgroup: alt.lang.asm

    W dniu 15.04.2026 o-a22:01, Kerr-Mudd, John pisze:
    On Wed, 15 Apr 2026 20:23:52 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc#<jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a15:40, makendo pisze:
    (forwarding to alt.lang.asm because you are comparing C with it)
    Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
    ohter asm related groups. Is this wrong aproach?

    DYM comp.lang.asm.x86?

    No!

    comp.lang.asm is an empty header for me on eternal september's feed.

    After question "is comp.lang.asm moderated?" ecosia.org AI answer today, quote:

    The newsgroup comp.lang.asm is generally considered an unmoderated Usenet group. Unlike comp.lang.asm.x86, which is known to be moderated, comp.lang.asm does not have an official moderation process and typically allows posts to appear without prior review.

    I see old posts published on comp.lang.asm, and last is yours: "Kenny
    Code for DOS", from 2023-04-24, mon. (without any answers).

    sig is overlong, and crowded, IMHO.

    I have so many things to communicate Poles - this is the reason of bit
    sig. But I try to be laconic.
    --
    Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, EU Efc-Efc|;
    tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
    Domowa s. WWW: <https://energokod.gda.pl>;
    Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
    Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
    UWAGA:
    NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From makendo@makendo@makendo.invalid to comp.lang.c,alt.lang.asm on Thu Apr 16 12:44:44 2026
    From Newsgroup: alt.lang.asm

    So what you're saying is that assembly can do anything that any other arbitrary language (that has to eventually compile down to the same
    machine code) can do? This should not be surprising to anyone.

    Not really. Just to say that C is indeed abstract, and not same as
    assembly. Compiler optimizations will make the abstractness of C more
    evident: for example, you can break down a complex process into many
    functions tail calling each other, and under -O2, the process will
    only take one frame of stack space, instead of naively eating up the
    stack with the call chain.

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Kerr-Mudd, John@admin@127.0.0.1 to comp.lang.c,alt.lang.asm,comp.lang.asm on Thu Apr 16 11:38:05 2026
    From Newsgroup: alt.lang.asm

    On Wed, 15 Apr 2026 22:40:55 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a22:01, Kerr-Mudd, John pisze:
    On Wed, 15 Apr 2026 20:23:52 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc#<jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a15:40, makendo pisze:
    (forwarding to alt.lang.asm because you are comparing C with it)
    Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
    ohter asm related groups. Is this wrong aproach?

    DYM comp.lang.asm.x86?

    No!

    comp.lang.asm is an empty header for me on eternal september's feed.

    After question "is comp.lang.asm moderated?" ecosia.org AI answer today, quote:

    The newsgroup comp.lang.asm is generally considered an unmoderated Usenet group. Unlike comp.lang.asm.x86, which is known to be moderated, comp.lang.asm does not have an official moderation process and typically allows posts to appear without prior review.

    I see old posts published on comp.lang.asm, and last is yours: "Kenny
    Code for DOS", from 2023-04-24, mon. (without any answers).


    I've only posted (xposted) asm code to ala, clax and comp. never to
    cla.

    This post would be a first; I'll see if it gets there.

    sig is overlong, and crowded, IMHO.

    I have so many things to communicate Poles - this is the reason of bit
    sig. But I try to be laconic.

    --
    Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, EU Efc-Efc|;
    tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
    Domowa s. WWW: <https://energokod.gda.pl>;
    Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>; Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
    UWAGA:
    NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

    --
    Bah, and indeed, Humbug
    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Rosario19@Ros@invalid.invalid to alt.lang.asm on Sun Apr 19 10:03:58 2026
    From Newsgroup: alt.lang.asm

    On Wed, 15 Apr 2026 21:40:36 +0800, makendo wrote:

    The 4th difference: Local variable.
    (Assembly can theoritically do the same but I don't have impression which one
    support this feature.)

    If you are talking about function-local data, there are multiple ways
    to do store them in an easy-to-clean-up fashion:

    - Volatile registers, for the shortest lived data. Calling other
    functions causes them to be overwritten with the function's
    return value or irrelevant data.
    - Non-volatile registers, for data that need to persist across
    function calls. You save the contents of them before using them,
    as your caller expects the contents of these registers to be
    intact once you return.
    - The stack, for long-lived function-local data when you are out of
    non-volatile registers. You manipulate a dedicated stack pointer
    register to allocate and deallocate space for your data.
    - Immediates, and the .rodata (ELF) / .rdata (PE) section, for
    constants and tables of constants.

    The notion of local variable allows you to ignore all of these in C,
    though. Assembly having multiple ways to store local data instead of
    one can make things fairly complicated to read, write and debug.

    (forwarding to alt.lang.asm because you are comparing C with it)

    in assembly pure that one use stack registers ecc, there are many ways
    to do workaround in low level, thinking of cpu, the data, the position
    of the data in memory ecc ecc not seen of C compiler. So the max
    optimization for cpu +memeory will be in pure assembly

    --- Synchronet 3.21f-Linux NewsLink 1.2
  • From Kerr-Mudd, John@admin@127.0.0.1 to comp.lang.c,alt.lang.asm,comp.lang.asm on Thu Apr 30 11:31:59 2026
    From Newsgroup: alt.lang.asm

    On Thu, 16 Apr 2026 11:38:05 +0100
    "Kerr-Mudd, John" <admin@127.0.0.1> wrote:

    On Wed, 15 Apr 2026 22:40:55 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc# <jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a22:01, Kerr-Mudd, John pisze:
    On Wed, 15 Apr 2026 20:23:52 +0200
    Efc|Efc#Jacek Marcin JaworskiEfc|Efc#<jmj@energokod.gda.pl> wrote:

    W dniu 15.04.2026 o-a15:40, makendo pisze:
    (forwarding to alt.lang.asm because you are comparing C with it)
    Great, but what is wrong with comp.lang.asm ? I subcribe it instead any >> ohter asm related groups. Is this wrong aproach?

    DYM comp.lang.asm.x86?

    No!

    comp.lang.asm is an empty header for me on eternal september's feed.

    After question "is comp.lang.asm moderated?" ecosia.org AI answer today, quote:

    The newsgroup comp.lang.asm is generally considered an unmoderated Usenet group. Unlike comp.lang.asm.x86, which is known to be moderated, comp.lang.asm does not have an official moderation process and typically allows posts to appear without prior review.

    I see old posts published on comp.lang.asm, and last is yours: "Kenny
    Code for DOS", from 2023-04-24, mon. (without any answers).


    I've only posted (xposted) asm code to ala, clax and comp. never to
    cla.

    This post would be a first; I'll see if it gets there.

    It didn't. clax is dead, IME.


    sig is overlong, and crowded, IMHO.

    I have so many things to communicate Poles - this is the reason of bit sig. But I try to be laconic.

    --
    Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska Efc|Efc#, EU Efc-Efc|;
    tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA; Domowa s. WWW: <https://energokod.gda.pl>;
    Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>; Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>. UWAGA:
    NIE ZACI-aGAJ "UKRYTEGO D+UUGU"! P+UA-a ZA PROG. FOSS I INFO. INTERNETOWE! CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>



    --
    Bah, and indeed, Humbug
    --
    Bah, and indeed, Humbug
    --- Synchronet 3.21f-Linux NewsLink 1.2