4 ms·

Note that this isn't unmodified Go; it's Go with some features for memory management, in particular having to annotate loops with the number of trips (see secti

Note that this isn't unmodified Go; it's Go with some features for memory management, in particular having to annotate loops with the number of trips (see section 6.3).

deaddodo 6y ago
It would have to be, unless you wanted to write a thin hypervisor in freestanding C, C++ or Rust to handle the syscalls/memory management required for the GC.
- pjmlp 6y ago
  That is perfectly doable in Go. Just like C, C++ or Rust you would need a thin Assembly help and that is about it. https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
  - deaddodo 6y ago
    Freestanding C requires nothing more than the bootloader be written in assembler and that's an architectural dependency; most I/O mapped, embedded devices simply require the binary be loaded in a specific location (usually an offset on ROM). CRT0 itself can also be bootstrapped in C. That's quite different than a low-level kernel bootstrap, which is what you linked. Regardless of whether you do it in Assembler or the aforementioned languages, you must build a hoist outside of Golang.
    - pjmlp 6y ago
      Try to implement malloc/free in freestanding C, or soft floating point for that matter. Inline Assembly doesn't count as C, isn't part of ISO C and any language can have such extensions, including Go.
      - deaddodo 6y ago
        Why would I need to, when it’s already been done? https://github.com/blanham/liballoc/ https://github.com/blanham/liballoc/ It’s not even uncommon, as liballoc is one of the top recommended allocators for hobby OSes. I never mentioned inline assembler. Whilst any decent OS will most definitely fall back on assembler, and I never claimed otherwise, it’s not a requirement. It, or another of the aforementioned, would be within the realm of standard Golang. You’re jumping through hoops to equate a language out of it’s intended use cases to ones completely within their’s. It’s not a knock on Go (or other GC’d languages), it’s just a reality of the compromise on specific features. You also couldn’t write an OS in a VM’d language without having a VM hypervisor; it doesn’t mean they’re bad languages.
        pjmlp 6y ago
        > There are 4 functions which you need to implement on your system: int liballoc_lock(); int liballoc_unlock(); void* liballoc_alloc(int); int liballoc_free(void*,int); So where is the ISO C implementation of those?
pjmlp 6y ago
As proven by Oberon, it can be made with unmodified Go as well. What it would be missing, and was fixed in Active Oberon, is explicit support for untraced references.
- sitkack 6y ago
  > untraced references could you explain that a little more. Are references in Oberon bidirectional? Meaning there is a list of every reference ever taken and by whom?
  - pjmlp 6y ago
    Common GC speak. Traced references are tracked by whatever form the language offers automatic memory management. Untraced references are a kind of safe pointers, basically the memory they point to isn't tracked by the GC/RC infrastructure and they are managed in some form of manual memory management, and can be used as part of unsafe code for pointer arithmetic. The languages then provide means of converting between both worlds, naturally it always requires making use of some form of unsafe code block.
    - sitkack 6y ago
      Ok, got it. Off GC Heap memory allocations. I thought it might be an Oberon specific concept. I'd like to see something like ref counting, but an actual ref list where there is a global list of references to an object.

Note that this isn't unmodified Go; it's Go with some features for memory management, in particular having to annotate loops with the number of trips (see section 6.3).

deaddodo 6y ago

It would have to be, unless you wanted to write a thin hypervisor in freestanding C, C++ or Rust to handle the syscalls/memory management required for the GC.

pjmlp 6y ago
That is perfectly doable in Go. Just like C, C++ or Rust you would need a thin Assembly help and that is about it. https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...
- deaddodo 6y ago
  Freestanding C requires nothing more than the bootloader be written in assembler and that's an architectural dependency; most I/O mapped, embedded devices simply require the binary be loaded in a specific location (usually an offset on ROM). CRT0 itself can also be bootstrapped in C. That's quite different than a low-level kernel bootstrap, which is what you linked. Regardless of whether you do it in Assembler or the aforementioned languages, you must build a hoist outside of Golang.
  - pjmlp 6y ago
    Try to implement malloc/free in freestanding C, or soft floating point for that matter. Inline Assembly doesn't count as C, isn't part of ISO C and any language can have such extensions, including Go.
    - deaddodo 6y ago
      Why would I need to, when it’s already been done? https://github.com/blanham/liballoc/ https://github.com/blanham/liballoc/ It’s not even uncommon, as liballoc is one of the top recommended allocators for hobby OSes. I never mentioned inline assembler. Whilst any decent OS will most definitely fall back on assembler, and I never claimed otherwise, it’s not a requirement. It, or another of the aforementioned, would be within the realm of standard Golang. You’re jumping through hoops to equate a language out of it’s intended use cases to ones completely within their’s. It’s not a knock on Go (or other GC’d languages), it’s just a reality of the compromise on specific features. You also couldn’t write an OS in a VM’d language without having a VM hypervisor; it doesn’t mean they’re bad languages.
      - pjmlp 6y ago
        > There are 4 functions which you need to implement on your system: int liballoc_lock(); int liballoc_unlock(); void* liballoc_alloc(int); int liballoc_free(void*,int); So where is the ISO C implementation of those?

pjmlp 6y ago

As proven by Oberon, it can be made with unmodified Go as well. What it would be missing, and was fixed in Active Oberon, is explicit support for untraced references.

sitkack 6y ago
> untraced references could you explain that a little more. Are references in Oberon bidirectional? Meaning there is a list of every reference ever taken and by whom?
- pjmlp 6y ago
  Common GC speak. Traced references are tracked by whatever form the language offers automatic memory management. Untraced references are a kind of safe pointers, basically the memory they point to isn't tracked by the GC/RC infrastructure and they are managed in some form of manual memory management, and can be used as part of unsafe code for pointer arithmetic. The languages then provide means of converting between both worlds, naturally it always requires making use of some form of unsafe code block.
  - sitkack 6y ago
    Ok, got it. Off GC Heap memory allocations. I thought it might be an Oberon specific concept. I'd like to see something like ref counting, but an actual ref list where there is a global list of references to an object.