#24571 - Abscissa - Fri Aug 06, 2004 6:51 am
I've been working on trying to get the current version of the D frontend for GCC (http://home.earthlink.net/~dvdfrdmn/d/) working together with devKitARM and about five minutes ago I finally got a piece of D code to run on the GBA!
To test it all, I've been using the project from my PDRomz 2.5 entry instead of doing something from scratch (Don't ask me why, I have no idea. Probably just laziness ;) ). So, the ROM I have to show for it is mainly that game (written in C), except there's now a one-line function in D that draws a tiny little flickering white pixel in the upper-left corner of the intro screen. It's not much, but I'm gonna work on something better to show soon (hopefully something that's not a minor hack of something else ;) ). I just wanted to get this out :)
This is the content of the D file:
| Code: |
extern (C) void testDFunc()
{
*((ushort *) 0x6000000) = 0x7FFF;
} |
The ROM is here if you're interested: http://www.twistedpairgaming.com/download/MyRobot19_WithD.gba
I'll also post back soon about how to get D working on devKitARM, but it's late right now and I think my brain's just about to shut itself off for the night ;)
#24574 - sajiimori - Fri Aug 06, 2004 7:31 am
Hey, nice work! Do you know how or if garbage collection is gonna work?
#24575 - Abscissa - Fri Aug 06, 2004 7:47 am
| sajiimori wrote: |
| Hey, nice work! Do you know how or if garbage collection is gonna work? |
Thanks :). I don't know for sure about the GC, it's been a large question in the back of my mind. I haven't actually done any dynamic allocation on the GBA at all, not with C's malloc or C++'s new. I think I might have to do finally do some dynamic allocating with D though, since I'm not sure if D can instantiate classes without using new, like C++ can. Even though I've never used them, I assume C++'s new works on GBA and I don't think that GC would be much fancier than that (unless it expects to run in a separate thread), so I'm guessing it should at least be possible and probably practical. It may require the standard D lbraries (Phobos), and I haven't attempted to compile those yet, so we'll see. Possible issues with Phobos aside, D allows a suprising amount of control over GC and memory allocation, so I'm hopeful about it. At the very least, it *might* be possible to effectively disable GC (and the need for it) altogether with some tricks involving overriding new and delete. Again, we'll see.
#24597 - MumblyJoe - Sat Aug 07, 2004 5:49 am
Is it safe to assume that D stack based or static global variables never have anything to do with garbage collection? If so you could try to disable support for GC altogether and let people link in their own C/C++ files with encapsulated memory allocation and freeing functions. I dont know what other bonuses D has that may get in the way on embedded systems.
Anyway, good stuff man.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#24600 - sajiimori - Sat Aug 07, 2004 6:47 am
If you're gonna use a more modern language, why not use the features it offers? There's no need to revert to manual memory management if GC works -- you could easily run the generational collector once per frame, and the full collector during intermissions.
#24601 - Abscissa - Sat Aug 07, 2004 7:07 am
| MumblyJoe wrote: |
Is it safe to assume that D stack based or static global variables never have anything to do with garbage collection? If so you could try to disable support for GC altogether
Anyway, good stuff man. |
Thanks. I'm almost certain we can make those assumptions. However, I'm just not sure that it's possible to instatiate a class on the stack. AFAIK, It's like Java or C# in that if you declare "MyClass object;" object is set to a null reference and you must say "object = new MyClass;" hence it's allocated on the heap, hence it's garbage collected. I'm just not familiar enough with D yet to know if there's a way arond it.
But I'll look into that once I get to it. Right now I'm trying to get D/devKitARM compiled with MSYS/MinGW (I've only been able to do it under Cygwin so far), and then I'll post it.
Actually, come to think of it, the current version of the D frontend for GCC uses a pretty out-of-date version of D, so until that gets moving along there might be a lot of D features that won't work right just yet.
| sajiimori wrote: |
| If you're gonna use a more modern language, why not use the features it offers? There's no need to revert to manual memory management if GC works |
Right, I just meant that if, for some reason, I ran into problems with using D's garbage collector on GBA, I could hopefully fallback to manual stuff instead of having to avoid using classes.
#24605 - sajiimori - Sat Aug 07, 2004 4:12 pm
Oh sorry, I meant to address my reply to MumblyJoe. =)
#24666 - MumblyJoe - Mon Aug 09, 2004 3:43 am
| sajiimori wrote: |
| If you're gonna use a more modern language, why not use the features it offers? There's no need to revert to manual memory management if GC works -- you could easily run the generational collector once per frame, and the full collector during intermissions. |
True. I would be interested to see if GC made any large impact on speed/size/whatever of code. Personally I have a dislike for GC in general but I understand it's useful for many things and can speed up development quite a bit.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#24684 - sajiimori - Mon Aug 09, 2004 5:53 pm
GC practically always makes code smaller, and modern GCs sometimes make code faster, but more often the time is just spent somewhere else (e.g. one big collection instead of lots of frees). By far, the main issue is the extra RAM usage from the bookkeeping, and there's even more usage for copying/compacting collectors.
OTOH, fragmentation can cause lots of waste on traditional allocators, and compacting collectors solve that, so once again it's hard to tell which method would come out on top in a given situation.
#24703 - MumblyJoe - Tue Aug 10, 2004 2:22 am
Hmmm. I'm not arguing about GC bieng faster - it probably is for all I know - but I would love to see a technical explanation if you can recommend any reading. I can see how compacting collectors would be useful, particularly with limited memory like on the gba, but I'm having trouble visualising exactly how having something watch memory for me intsead of just doing it the old fashioned way is much faster, although it is much easier. Besides that, I like to KNOW I wont go over the availiable memory on the gba no matter what, so I usually calculate what I can do before I even begin an idea, so dynamic memory on embedded systems sort of scares me, especially when I'm not sure when it get freed.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#24707 - sajiimori - Tue Aug 10, 2004 2:55 am
Knuth has a section on GC, but that's the only text I have on it.
I wouldn't suggest that GC is much faster, or even faster at all in general. Depending on the situation it can be a lot slower. The impact on speed depends on lots of factors, and many of them don't apply to a cacheless system like GBA. On a system that relies heavily on caching (like newer PCs), it can help a lot to keep your memory defragmented.
In a GC environment, object creation is fast -- usually just a pointer increment -- and collections can be delayed until a convenient time (which, BTW, allows you to know exactly when memory will be reclaimed). In traditional heap allocation schemes, a search often has to be run to find available space during allocation, and memory must be freed just before the last reference is lost.
In any case, if you don't like dynamically allocating memory GC will be just as useless as malloc/free, and there's not much to discuss. ^_^
#24716 - tepples - Tue Aug 10, 2004 5:54 am
Could a GC use a strategy of incremental compaction of the heap in EWRAM, with a bit of work done every frame based on vcount? Or would that eat too much battery?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#24720 - sajiimori - Tue Aug 10, 2004 7:48 am
Theoretically, the amount of compacting work required per frame should stay pretty low. Over time, the more permanent objects will settle toward the start of the heap, and short-lived objects will tend to stay near the end, resulting in almost stack-like behavior.
Compaction is only needed when an older object is released while newer objects are retained. In this situation, it's important to resist the temptation to "reduce the workload" by filling the gap with the last objects in the heap (i.e. the newest ones) -- this would result in rapid leapfrog behavior where new objects are constantly being moved backwards over older objects, and the stack-like nature of the heap is completely destroyed.
A lot of time can be saved by using the generational approach, which scans the newer objects more often, while only periodically checking older objects. The theory is that the longer you've kept an object around, the more likely it is you'll need it for a little longer still.
#24727 - SmileyDude - Tue Aug 10, 2004 4:39 pm
As far as GC versuses non-GC, you can look at the page on the D website -- http://www.digitalmars.com/d/garbage.html.
I don't know how valid that is, but it seems to make sense to me.
_________________
dennis
#24728 - sajiimori - Tue Aug 10, 2004 5:06 pm
Many of the points listed on the D site are questionable or outdated.
| Quote: |
(Reference counting methods are not a general solution anyway, as circular references never get deleted.)
|
Cycle detection has been around for a while.
| Quote: |
If the destructors become irrelevant, then there's no need to set up special stack frames to handle exceptions, and the code runs faster. |
Modern C++ compilers use zero-cost exceptions, so there's no overhead until an exception is actually thrown.
| Quote: |
Garbage collection kicks in only when memory gets tight. When memory is not tight, the program runs at full speed and does not spend any time freeing memory.
|
This is the antithesis of modern, incremental GC technology. I don't want my collector "kicking in" when I'm in the middle of my work, and having to wait for it to finish.
| Quote: |
Garbage collected programs do not suffer from gradual deterioration due to an accumulation of memory leaks.
|
This isn't an argument about speed. It's an argument about the ease of writing bug-free programs.
| Quote: |
Garbage collectors reclaim unused memory, therefore they do not suffer from "memory leaks" which can cause long running applications to gradually consume more and more memory until they bring down the system. |
Memory leaks are still possible when you hold references for longer than you intended.
#24778 - torne - Wed Aug 11, 2004 1:19 pm
D's page on it is pretty old, yeah. The 'modern' reason for GC is that typically your machine spends so much time doing nothing there's no reason to clutter up the brief 'busy' periods with nasty memory management.
This is sometimes the case on the GBA, really, when most processing is being done in vblank, leaving little to handle during vfill. A generational GC with incremental collection of the long-lived heap could work very well, doing a run in the vfill every few frames - it could even allow hblank interrupts if it was incremental (so you can keep doing palette effects and mixing and stuff)
Writing such a GC is pretty difficult, though. I don't know which implementation D uses, but the Boehm GC used in a lot of GC'ed C/C++ code would probably be unsuitable.
Personally I'll stick with entirely static memory allocation, because that way I know I will never have an allocation failure. I'll have enough headaches dealing with allocation failures on Symbian in my day job ;)