Browse thread
ocaml doesn't need to optimize on amd64??
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Kuba Ober <ober.14@o...> |
| Subject: | Re: [Caml-list] ocaml doesn't need to optimize on amd64?? |
> > Yeah, but my area of interest is really embedded realtime stuff, running > > typically on architectures which are quite resource constrained. On some > > of those your typical GC wouldn't even fit in the code memory. And I'm > > not even (most of the time) using dynamic memory allocations. None of my > > code really calls for any sort of boxing -- there's no need for it. All I > > need is C that is more expressive and easier to optimize. No run-time > > variants, really, all types are known and fixed, and data is at fixed > > locations in memory, or on the stack, or occasionally on the heap which > > is manually managed (C-like). > > > > Of course that pertains to the code that gets generated, because I should > > be able to use abstract concepts while writing the code. If I pass a > > function to a function, it doesn't necessarily mean that the compiler > > must emit the code for the former, and that the latter should actually > > call (as call machine instruction) the former. > > This may be something you have seen before and dismissed, and it's not > really OCaml at all, but have you looked at PreScheme? It's a scheme > dialect (and, in fact, runs *un-modified* in a scheme interpreter), > plus a compiler that turns it into optimized C of the type you're > talking about. (For example, one optimization is that all > higher-order procedures are beta-substituted away at compile time.) > It might not really fit your needs, but perhaps there's some ideas you > could steal there, in any case. (The scheme48 guys used it to write > the VM for scheme48, which sounds to my un-expert ears like it would > have a lot in common with the tasks you're looking at doing.) If it turned it into C-- it'd be even better, because I can't count much on C compilers for my platforms either: Zilog Z8 compiler and assembler/linker has bugs which produce wrong code, and for SX28 there's, afaik, only one C compiler that isn't quite there yet anyway. C-- would be easier to generate code from. Right now my hackish platform runs in LISP, so Scheme wouldn't be so much different, but I don't really know how macros are done in Scheme, and I kind of depend on them. Cheers, Kuba