Date: Tue, 09 May 2000 22:14:27 +0100 From: Karl Pielorz <kpielorz@tdx.co.uk> To: J McKitrick <jcm@freebsd-uk.eu.org> Cc: chat@FreeBSD.ORG Subject: Re: assembly vs C Message-ID: <39187FB3.7C1D34@tdx.co.uk> References: <20000509212637.A73322@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
J McKitrick wrote: > > I've heard some debates recently, mostly by 'old-school' hackers from the > C64 days who are calling for a return to machine language. They claim that > CPU speed, memory size, and HD space will begin to plateau soon, and that ML > would bring a much needed return to efficiency and clean coding. This has absolutely nothing to do with FreeBSD! - But, it's on -chat, so what the hell... :) [This is also a long post, perhaps because of the lack of FreeBSDism, it should be continued in off-list mail?] I used to be a C64 'junkie'... I've written stuff in 6502, heck - I grew up with it and the C64, and remember the days when 68k (68000) looked like 'BASIC' compared to 6502... I disagree with the above statement, on the basis that people like Transmeta have begun proving this wrong... I also disagree that things have 'plateau'd yet... Moore's law is still holding true, hard drives are still getting bigger - and memory cheaper/faster. I stick with FreeBSD as these improvements net us real gains, instead of being spent on the user interface, or more complex 'over the top' specifications / implementations of the O/S. On a 'simple machine' in the old days, programmer vs. compiler - will sometimes result in the programmer winning... It's how you got the C64 to do the 'amazing' things you could get it to do, because you needed the speed of machine language (as the CPU was slow), and a 6502 has all but a handful of instructions, I used to know people who could program in hex directly! [not too hard on a 6502!] - As well as know at what state the CPU was every step of the way. The only way the programmer would win would be because of inadequacies in the compiler, which considering it was 6502, and a while ago - was more of a probability than it is today. These days, your up against multiple platforms, CPU's with hundreds of instructions, and a hugely complex 'machine', with caches, branch predictors, pipelines, and all sorts of wizardry. Sure a programmer can by hand, probably figure it all out - but these days you put your faith in the compiler, and it _can_ do as good, if not better... Compilers these days are more akin to chess players. Unless your Kasparov, they will (on the whole) make better decisions than you can. Sure they still need 'hints' and the like, but they have the best 'plan view' of the state of the program/process/possibly machine, and can normally decide what's best based on what's going on, what's going on after the current operation, and what went previously... (There not infallible - yet, by any means). > The other side of the coin argues differently. I can think of 2 arguments > against: first, OOP and C++ were developed almost expressly to make it > easier to deal with the size of today's apps. Modularity only goes so far, > they claim. Objects are needed to further simplify development and > maintenance. What is needed is a clearly defined, unambiguous interface between 'components', which OOP mostly satisfies - whilst still keeping a semblance of 'real world' about it. Whether CPP satisfies this, is probably open to debate... CPP is an improvement - is it the 'ultimate' solution? - I don't think so, and don't think we're in a position to tender the 'ultimate' language yet by a long shot... Some may be better than CPP some may be worse... > The other point is illustrated by Unix itself. ML was > abandoned for C, since compilers are advanced enough in time and space > optimization to make hand-coding unnecessary, even obsolete for everything > but device drivers. And arguably even in device drivers - especially as the push continues to "decouple" the bus/machine infrastructure from the driver itself... > What does everyone think about this? Will there ever be a need for ML > again, besides optimized device drivers? Or will advanced compilers and OOP > replace low level programming for most tasks? Even though C is not OOP, it > is low-level enough that a good compiler and a tight C program make the > benefits of ML almost irrelevant, correct? In everything I've done recently, where I think I've "outsmarted" the modern day compiler, the answer has been 'I was wrong' or 'I couldn't have done it better in ML'. However, the compiler can still fall short in a number of ways, which either require machine language to fix - as it's not open to ambiguity (as a result of sacrificing portability perhaps?) - and the compilers are still open to bugs / 'wrong assumptions' for the moment in 'process' time they're looking at. Relating to FreeBSD - if it was written in machine language by a human / programmer, would it be 'better' than the current 'C' translation into machine language? - possibly. Would parts of it be beyond human comprehension if you 'step back' and look at it? - Probably not, but it would significantly shift the way things are done, and 'passed around' the internals of the operating system, or at least it would if we still wanted to keep things comprehensible... Just my $0.25 :) -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39187FB3.7C1D34>