search for: 1kloc

...ar with HLVM, albeit for a new VM that uses a new representation. I found the combination of OCaml and LLVM to work extremely well. OCaml makes it very easy to manipulate programs and its LLVM bindings make it very easy to JIT compile and execute native code. My entire VM (including GC) is only 1kLOC. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

Hi guys, first of all let me say "hello" to everyone. Its the firt message for me in this list and I'm pretty happy that I'll be able to finally start working with LLVM. I've a question for you all if you can help me: a few years ago I've implemented a simple VM for a language we're using in my company. The VM JIT compiles a simple bytecode and executes it.

...t uses > a new > representation. I found the combination of OCaml and LLVM to work > extremely > well. OCaml makes it very easy to manipulate programs and its LLVM > bindings > make it very easy to JIT compile and execute native code. My entire VM > (including GC) is only 1kLOC. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm...

...niel! There are more candidates for tiny/. They are all <20k > LOCs and all we'd have to do is to move their code into a single file. > bochs or arc come into my mind. arc I have (later in the series), bochs I feel like is maybe a bit too big. I'd put the limit for tiny well below 1kloc including whitespace and all that. bochs might be a candidate once we've helperized a few more things perhaps. btw I drmm_ version of vram helpers would help a bunch of these drivers I think. -Daniel > > > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> >...

...niel! There are more candidates for tiny/. They are all <20k > LOCs and all we'd have to do is to move their code into a single file. > bochs or arc come into my mind. arc I have (later in the series), bochs I feel like is maybe a bit too big. I'd put the limit for tiny well below 1kloc including whitespace and all that. bochs might be a candidate once we've helperized a few more things perhaps. btw I drmm_ version of vram helpers would help a bunch of these drivers I think. -Daniel > > > > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> >...

Hi, I've noticed that the opus-tools is using a really old version of Speex's resampler code - a version that I've seen fail in the wild first-hand under low resource circumstances. I've actually submitted patches for some issues in the Speex resampler a while ago (and IIRC they were accepted): http://lists.xiph.org/pipermail/speex-dev/2009-November/007541.html ,

...k >> LOCs and all we'd have to do is to move their code into a single file. I meant <20k file size, not LOCs. >> bochs or arc come into my mind. > > arc I have (later in the series), bochs I feel like is maybe a bit too > big. I'd put the limit for tiny well below 1kloc including whitespace > and all that. bochs might be a candidate once we've helperized a few > more things perhaps. True. The largest tiny driver is repaper with ~1.1k LOCS. Reading this code, it seems like it has reached an upper bound of what is feasible. Best regards Thomas > &gt...

Because it is. Huge congrats to everyone who made this kind of refactoring happen! Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org --- MAINTAINERS | 2 +- drivers/gpu/drm/Kconfig | 2 --

Because it is. Huge congrats to everyone who made this kind of refactoring happen! Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Gerd Hoffmann <kraxel at redhat.com> Cc: virtualization at lists.linux-foundation.org --- MAINTAINERS | 2 +- drivers/gpu/drm/Kconfig | 2 --