Low-level C target for Monkey?
Monkey Targets Forums/User Targets/Low-level C target for Monkey?
| ||
| Hello! I thinking about doing a low-level C target for Monkey to be able to create things like windows drivers, linux kernel modules, or even operating system. I'm experienced programmer, but I haven't dig into monkey yet, so I'd like to ask several questions. 1) I'd like to use automatic propagated error values as exception handling algorithm, do you think it is a good idea? Well it does add some overhead to the runtime, but it is easier and doesn't effect control flow like setjump/longjump for example. 2) I'd like to use automatic reference counting instead of garbage collection, because it is predictable and easy to implement, and obviously try to avoid loops, what do you think about it? 3) Will monkey compiler handle generics for me or I need to implement it myself? 4) Using Monkey for low-level code I need to provide users with some low-level facilities, does Monkey supports something like pointers and pointer arithmetic? If not what is the best way to simulate it in the language? |
| ||
| Also is there any good tutorials about creating new targets for Monkey? Do I have to recompile the compiler each time I work on my custom target? Does Monkey compiler suuport plugins of some kind? Is there any metaprogramming facilities in Monkey? |
| ||
| 1): If I'm understanding you correctly, you want to overhaul exceptions into something like the C standard library's error handling functionality? I'm not exactly an expert on the subject of error handling, but isn't the current exception-system good enough? I'm really not the guy to ask this, so if anyone else is reading this thread, they might have better input on the subject. 2): I've thought about this idea before, and it's definitely possible. 3): Yes, generics are completely handled by Monkey's compiler. 4): Kind of... Monkey uses nothing but pointers currently (For generated code, and most externally bound code). This means that every type you use is a pointer. In C++11 terms, this would mean that everything at face value works like a 'shared_ptr' (When you factor in garbage-collection/reference management). So, if you were to write something like: You'd end up with 'char*' as the type. Which of course means you could write a "CString" class which abuses this (I've tried it). Monkey's not going to give you smaller integers, either. You'd need to write that into the compiler, or potentially make them target-specific. If I remember right, Brucey from the BB/BMX community was recreating the BlitzMax compiler by forking 'transcc' (Monkey's compiler). That compiler has low-ish level functionality provided (Pointer types and other integer types). I'll be honest, I think this is an awesome idea, but the fact is, you'd need to really do some work on the compiler. Plus, I don't see why you can't work off of the standard C++ target, and just use the new smart pointer functionality for a hybrid environment. But, hang on, let's break this down. So, Monkey's a game-oriented language, it's fantastic, but game-oriented. It compiles to multiple languages, and is therefore partially hindered by this. Using lower-level or platform specific functionality can be done in Monkey, but the fact is, if you want to use lower-level ideas in Monkey, you'd need to modify the compiler. For one thing, the multi-target idea would be a no-go. Sure, it could be useful as a sort of "front-end" kind of thing, but it's no realistic when all you'd be dealing with is C and C++. Monkey's also built around the idea of garbage-collection/reference counting (The current C++ GC's a bit of a hybrid, really). Though, technically, there's nothing stopping you from making it support manual object management, and stack-based structures. The thing is, I'd love to have a language like Monkey do this, but it's also a lot of work to effectively make a different language. Heck, Mark's source for 'trans' is pretty awful syntactically; if I were in your shoes, I'd write a new compiler (In Monkey) based off of that one. It's a solid compiler, but overhauling it could cause long-term problems. I'll end this off by saying that I love the idea, but it's not realistic unless you're seriously dedicated. A friend of mine has gotten into D, and at this point, it's what I want Monkey to be in some ways (At least as far as control goes). In many ways, D and Monkey share similar designs, the main difference being the perspective on abstraction. That, and D is C-like, where as Monkey's its own breed of BASIC. But, you know, not terrible like VB. I'm sure there's tutorials for creating targets, but you're probably better off making a new compiler using Mark's as a base. That's assuming you're still dedicated to doing this with Monkey. I definitely think the driver idea would be awesome, but it would need either its own wrapper APIs, or something to generate external bindings for you. Also, by meta-programming, are you referring to reflection, or something more advanced? Because, Monkey has reflection for everything but templates/generics (Something that we really need to get working at some point). Here's the reflection page. If you're looking for some kind of scripting language built around reflection, there is MiniC (Also see this version). The big draw-back is templates/classes not being supported by reflection. That was a long post, and I only scratched the surface. What makes you think Monkey's the best option for this kind of thing? I certainly like the idea, though. I'd say try D for lower-level environments if you're not fixed on Monkey. I should also bring up the fact that Monkey's standard C++ target is good enough to produce code fast enough (Thanks in part to GCC) to run on mid-range embedded systems like the Raspberry Pi. It's also pretty optimizable as far as C++ output goes; the 'Array' class, and classes based on it can be broken down into SSE and AVX, for example. Anyway, those are my thoughts. Oh, also, here's an old thread where I made some comments about my adventures in external Monkey code. EDIT: Also, see this post about dealing with external C++ files. In fact, here; that's every single forum post I've made. I've talked about code generation once or twice, dealing with external C and C++, quirks about the compiler, etc. They're sort of spread out, though; I'm basically too lazy to go through all the posts. And if you look at a couple of my modules, you can see several examples of what Monkey can do with external code, currently. You should also look into Mojo's source (Including the 'brl' module's native files). I'd recommend looking at my code from a purely structural standpoint, as the more complicated stuff can be found in Mark's modules. (There's also some hacks the compiler does to make things stack-allocated. On top of that, there's even some weirder things it does to fake one type as another) |
| ||
| I wrote a simple one: There are 3 strings to edit: SavePath="/root/translated/" GameName="roguefromspectrum" Path="/root/Dropbox/monkeygames/roguefromspectrum/" save path is where you want the .c and .h files and path is where the monkey files are stored. I wanted to write a game for ZX Spectrum and also be able to have it in monkey for other platforms. When I tried the code on the spectrum it crashed (probably something to do with the stack) There are only 3 types unsigned char, signed char and int. I had to simulate signed and unsigned chars wrapping around when they get too big or too small this is important for computers with small memory where ints are a waste. To get this behaviour you have to do this in your monkey game code local r:unsignedchar=new unsignedchar r.Assign(6) 'makes r equal 6 r.Add(12) 'adds 12 to r r.Minus(3) 'takes 3 away from r You can write your own multiplication and division If you understand how they affect chars here are the types that simulate chars in your monkey game: Its not perfect by any means, it takes care of functions and generates the .h header files. It can handle local and global data types. Any type of struct is not supported. You can only use arrays to store data (2 dimensional arrays are supported) |
| ||
| LeFF, why? I can't think of a single reason why you would want to use monkey for the things you describe. It is not a suitable replacement for C/C++. |
| ||
| why? I'm very interested in this topic. Although for absolutely none of the reasons LeFF listed. I'm interested in using (and do use) Monkey for general purpose programming. I think a number of others are as well, That's why Mark added '#GCmode=2' for the cpp target. I understand that any changes that move monkey more towards general desktop development will break compatibility with the other targets. But while we all hope to see a true successor to BlitzMax, it's nice to dream about. Monkey *could fill that role, but it would need abandoning it's lineage. |
| ||
| @GW_: That's not necessarily true. Other than the lack of pointers and other integer types, Monkey's not in bad shape for replacing BlitzMax. The only thing it absolutely needs is stack allocated variables (Would make external bindings easier). Personally, I'd still like pointers, though. When I first bought Monkey, I was thinking it was a language that was purely built for compiling on many different targets, and everything had to be abstracted from them. The fact is, with a bit of work, Monkey could also fill a different category: Using the same language for different platforms. Basically, other than some problems with lower-level functionality, this is true. The fact is, you can write target/language dependent code, and portable code. Most modules are portable, as they don't need external languages; Trans takes care of it. And the rest are usually designed to be capable of having native/external back-ends. I honestly think that at this point, Monkey should promote portable code wherever possible, but still provide functionality to deal with hardware and/or software specific features. I've actually considered forking Monkey for these very reasons; basically, it would just be Monkey, but you'd also have the option of writing less-portable code. I did this once by hacking in different integer types, but that was a while ago. Just some food for thought, but I do think Monkey either needs a fork that allows both portable and non-portable code (From the language itself). Either that, or Mark adds this kind of support, but I doubt that'll happen. I've also thought about writing my own implementation of 'transcc', which would be designed around this concept. |
   |