>>11
Only an idiot would make a language without GC in 2012 and expect anyone to use it.
Name:
Anonymous2012-10-02 23:53
>>11,12
This reminds me, I've been meaning to ask you this for a long time, it's 2012, when will we see an architecture featuring GC? Programming assembly is so effing annoying without GC.
>>13
Intel tried it with the iAPX432, but the Jews in the marketing department wanted to extend the 8080 instead, and that's how we have the x86 shit today.
>>13-16
A description of the iAPX432 reads like a laundry list of everything bad about CISC.
A better approach might be to add a few very fast primitives (think fastcall) and push all the intelligence up to user software instead of using microcode. I suppose it's possible that GC algorithms just don't have any isolated component that is computationally intensive enough to benefit from this - that would certainly explain why it's never been done.
this just cracks me up how everyone thinks that Go is the next C just because Ken Thompson worked on it even though it is shit slow, keeps all the bad parts of C, does not use OO, and everyone scoffs at D even though it is almost as fast as C++ and has all the features that everyone jerks off for in other languages. I really do hope Go becomes successful just to see people get stuck using a garbage collected language stuck in the C paradyme
>>20
The problem with the 432 was that all the protection-related features it provided couldn't be disabled, incurring overhead for the checks even when it's not necessary. You can run a 386+ in "flat" mode if you don't need segmentation, and turn off the paging too.
>>23 So like Java.
Java has only a superficial resemblance to C only by its curly braces syntax and primitive type system. garbage collection allows major design differences in how objects and types can be created, Go doesnt take any advantage of that and stays with C style handling of memory objects
>>24
Actually, segmentation on the 386 and later is always on - "flat mode" means loading the (mostly) programmer invisible segment descriptor caches with values for a flat mapping. You can even use some undocumented instructions to load the caches directly - this will let you do fun things like real mode with paging (Google for LOADALL).
Name:
Anonymous2012-10-03 5:42
>>26
I'm pretty sure x86 processors optimise for the special case of flat mode. By the way, segmentation is disabled in long mode. Also, loadall was undocumented and doesn't exist on post-386 processors.
>>27 LOADALL may be gone but the descriptor caches are still there. If they were not, ``big real mode'' would not be possible. The BIOS is required to set up big real mode when it boots, so they can't just get rid of it.