GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    julesh (julesh@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 02:15:55 JST julesh julesh

    It's likely I have absolutely no idea what I'm talking about here, but:

    If you're trying to compile a language with features like continuations to machine code, I wonder if it would be a good idea to ignore the cpu's stack, allocate your entire memory to heap and roll your own linked list structure to store your local variables. Function calls become significantly slower because you have to make a call to malloc to get a new frame, but the upside would be that reordering the stack becomes extremely cheap and no longer involves memcpy

    In conversation about 5 months ago from mathstodon.xyz permalink
    • Embed this notice
      VojtechStep (vojtechstep@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 02:21:46 JST VojtechStep VojtechStep
      in reply to

      @julesh that kinda sounds like what Chicken scheme does? Except with the twist that as an implementation detail, you also try to keep your heap on the stack as long as possible https://www.more-magic.net/posts/internals-gc.html

      In conversation about 5 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        CHICKEN internals: the garbage collector | More magic
    • Embed this notice
      julesh (julesh@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 03:02:13 JST julesh julesh
      in reply to

      I am pleasantly surprised by how much this isn't a bad idea

      In conversation about 5 months ago permalink
    • Embed this notice
      Bartosz Milewski (bartoszmilewski@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 03:13:32 JST Bartosz Milewski Bartosz Milewski
      in reply to

      @julesh I think we are cursed with the ancient processor architectures tied up to stack machines. It seemed like a good idea back in the 20th century. Now you may have a computer with terabytes of memory, but you still blow your fixed-size stack on a recursive procedure.

      In conversation about 5 months ago permalink
    • Embed this notice
      psu_13 (psu_13@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 05:19:21 JST psu_13 psu_13
      in reply to

      @julesh Didn't SML/NJ do essentially something like this? The "call stack" was heap allocated.

      <google>...

      Yeah something like this

      https://www.cs.princeton.edu/~appel/papers/stack2.pdf

      In conversation about 5 months ago permalink
    • Embed this notice
      Jencel Panic (abuseofnotation@mathstodon.xyz)'s status on Wednesday, 08-Jan-2025 17:08:07 JST Jencel Panic Jencel Panic
      in reply to

      @julesh How do you use the stack at all, if your functions can be passed around (and their scopes, saved)?

      In conversation about 5 months ago permalink
    • Embed this notice
      Rhialto (rhialto@mathstodon.xyz)'s status on Monday, 20-Jan-2025 04:42:31 JST Rhialto Rhialto
      in reply to

      @julesh You just reinvented the IBM 360/370/zArch calling convention.

      In conversation about 5 months ago permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.