> I partially agree with you, but anything in hardware that isn't > directly represented by C semantics is a fair game for using > __asm's. In fact, it is the only way to make your software look > good on a particular platform. I don't know how to fix that with > C and it seems that the rest of the posters on this thread don't > really know either. But this is a problem.
Well, of course it's a contradiction (dilemma, I suppose), so, no, you can't fix it. But one could define a machine-independent mechanism to implement machine-dependent extensions to the C language and to a large degree that is what inline assembly as well as .s files are all about. I imagine that brucee and forsyth, with their intimate knowledge of the Plan 9 C development system could easily provide such tools as inlining. My limited understanding suggests that the optimisations you refer to: > The problem is not register allocation per se, but how it ties into > instructions scheduling, piplining and all that jazz. And no, you can't > beat a smart compiler on architectures as complex as AMD64 and EM64T. are best done by 8l or equivalent, specially when it comes to inlining functions in a previously separate source file. But I'm no expert, I imagine that the compiler might need to supply a little more detail to assist. I would like to see such issues addressed, however, as the Plan 9 development environment seems more robust in this area than the unmanageable monstrosity that is GCC. It's really a pity that on this list the only people with the spare cycles to deal with this issues are those who feel a need to prove that Plan 9 can be as good as, say, Linux, to the competing camp instead of concentrating on evolving Plan 9's own strengths. The comparison with dinosaurs and small, furry mammals keeps coming to mind: little did the furry ones know that conditions would eventually change to favour their fur against the dinosaur's scales, but they didn't evolve towards scales and size just because it was the fashion of the day. ++L
