Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cello – High Level C

libcello.org

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Cello – High Level C

#51

Post by kazinator »

The strategy in the GC for determining the stack top for hunting GC roots will not work on all architectures.

On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame, and thus the scan will miss some GC roots.

In TXR Lisp, I used to use a hacked constant on aarch64: STACK_TOP_EXTRA_WORDS. It wasn't large enough to straddle the area, and so operation on aarch64 was unreliable.

http://www.kylheku.com/cgit/txr/commit/?id=3aa731546c4691fac...

A good stack-top-getting trick occurred to me: call alloca for a small amount of memory and use that address. It has to be below everything; alloca cannot start allocating above some register save area in the frame, because then it would collide with it; alloca has not know the real stack top and work from there.

Since we need to scan registers, we use alloca for the size of the register file (e.g. setjmp jmp_buf), and put that there: kill two birds with one stone.

http://www.kylheku.com/cgit/txr/commit/?id=7d5f0b7e3613f8e8b...

Re: Cello – High Level C

#52

Post by kazinator »

I'm left wondering about the iteration example that is also quoted in the home page:

https://github.com/orangeduck/Cello/blob/master/examples/ite...

Okay, so the vector is garbage-collectable once the function terminates ... but it has references to stack-allocated integers i0, i1 and i2. That leaves me wondering: won't the GC walk these and trample on stack memory that has been deallocated/reused.

(Maybe those integer values have a tag right in the val pointer that gets the GC to avoid dereferencing them.)

Re: Cello – High Level C

#53

Post by tjalfi »

pmiller2 wrote: post #33
PeCaN wrote: post #24

Earlier quoted context omitted.

>There's no reason a C99 compiler can't do those optimizations. No, there actually is, the C standard says structs have to be laid out in memory in the same order they're written and C has much weaker aliasing rules.

C99 has the restrict keyword, which guarantees that the pointer won't be aliased. As far as reordering struct members, there's no reason why an implementation can't provide that as an optional optimization you must explicitly turn on. Providing such an optimization and corresponding compiler flag would not disqualify it from being a conforming implementation.

There have been compilers that did this optimization.

179.art, one of the SPEC2000 benchmarks, has some poorly laid out structs. Sun Microsystems was the first company to introduce targeted optimizations for this benchmark.

GCC also had an optimization pass[0] for this. It may have been removed.

[0] https://www.research.ibm.com/haifa/dept/_svt/papers/golovane...

Re: Cello – High Level C

#54

Post by jessaustin »

pmiller2 wrote: post #18
noncoml wrote: post #14

Just my opinion, don't mean to be inflammatory, but if the user has to know and manually manage stack vs heap objects, then I wouldn't call it "High Level" language.

Then just allocate everything on the stack and use the optional garbage collector: http://libcello.org/learn/garbage-collection

Allocating on the stack doesn't need GC.

Re: Cello – High Level C

#56

Post by pmiller2 »

jessaustin wrote: post #54
pmiller2 wrote: post #18

Earlier quoted context omitted.

Then just allocate everything on the stack and use the optional garbage collector: http://libcello.org/learn/garbage-collection

Allocating on the stack doesn't need GC.

No, but it makes it easier (more “high level”) when you don’t need to explicitly deallocate things, ever.

Re: Cello – High Level C

#57

Post by mbreese »

tyingq wrote: post #6
aerovistae wrote: post #3

Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.

"Why does this exist? I made Cello as a fun experiment to see what C looks like hacked to its limits. As well as being a powerful library and toolkit, it should be interesting to those who want to explore what is possible in C." "Can it be used in Production? It might be better to try Cello out on a hobby project first. Cello does aim to be production ready, but because it is a hack it has its fair share of oddities"…

I found their FAQ to be refreshingly honest. This is in no way suited for large projects or where multiple people will be contributing. A case study sounds like a good description.

And the authors seem quite okay with that.

Re: Cello – High Level C

#58

Post by jopsen »

drongoking wrote: post #41

Isn't this sort of what Glib is getting at? Bringing higher level data structures and capabilities (extendable arrays, hash tables, heaps, etc.) into C. https://developer.gnome.org/glib/stable/glib-data-types.html You don't get Cello's macros, and it uses reference counting instead of invisible garbage collection, but you get a lot of fun high-level capabilities.

And if you really want to go high-level wouldn't Vala be the language?

Re: Cello – High Level C

#59

Post by rs23296008n1 »

Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler.

Raises the question of how usefully far you can make C twist using macros / preprocessor.

Candidates like Forth or Lisp seem possible. A few weekends at most. Might need to take a few liberties.

Python... Perhaps if you implement a less dynamic subset? Duck typing may trip you up. To what extent?

What about Elixir?

Re: Cello – High Level C

#60

Post by war1025 »

jopsen wrote: post #58
drongoking wrote: post #41

Isn't this sort of what Glib is getting at? Bringing higher level data structures and capabilities (extendable arrays, hash tables, heaps, etc.) into C. https://developer.gnome.org/glib/stable/glib-data-types.html You don't get Cello's macros, and it uses reference counting instead of invisible garbage collection, but you get a lot of fun high-level capabilities.

And if you really want to go high-level wouldn't Vala be the language?

Vala is actually a really pleasant way to interact with the various bits of the Gnome environment.

It's a shame, in my opinion, that it never really received widespread love.

I think all serious work on it stopped about a decade ago.

Post reply on HN