sergio masci wrote: >> Even if you take this as a excuse for why C was so poorly designed, it >> still doesn't excuse its widespread use today. C got popular because >> it tagged along with Unix and for other marketing reasons like that >> compilers were available cheaply or freely. > > Don't be so dismissive of that tiny little word "free". It tends to be a > VERY powerful incentive. I wasn't being dismissive about it and completely agree. > Ok so rather than simply write another C compiler I took the plunge and > tried to do something better. How far did this actually get me with you > an affirmed C detractor. In another post (same thread) you actually > mention that although XCSB is purportedly not a toy and it is not C you > haven't tried it. I've tried on various occations to get feedback from > you (through this list) about what features you would like to see in a > language but all I've been able to glean is that you'd like very strong > type checking and the language should really be PASCAL. I never said the ideal language is Pascal, only that Pascal did get a lot of things right and I usually use it as a counter-example to C because I know it pretty well and I have my own version of it. There are several reasons I haven't tried XCSB. First no customer has demanded it, while they have demanded HiTech C and Microchip C18 occasionally. As a result I have both of them. Second, no matter how great a job you do, I'm nervous about anything not from Microchip. If Microchip had a compiler for a decent language, I might actually try it, especially if it didn't do some of the brain dead things C18 does (really stupid stack and calling conventions). Third, while I'm not stuck on Pascal, Basic is a real turn off. Whether deserved or not, there is a certain perception about it. Even when customers don't care much what language I use, I don't want to have the conversation of having to defend the use of Basic. You would have been better off calling it something else even if the syntax was heavily based on Basic. So where does that leave people who want to innovate and provide a better language? Unfortunately in today's world of microcontrollers I think a new language can only come about one of two ways. First a company like Microchip supports it as part of their development suite. Second anyone else has to provide it for free so some people who are less in a position like I am can experiment with it and make it gain some ground. If it does and the hardware vendor picks it up, guys like me can finally get to use it. For my purposes a standard is not that big of a deal since I'm not too concerned about porting code between PICs and other microcontrollers. Eventually for general purpose wide acceptance a standard is important though. I think if you want to see XCSB take off, you need to get Microchip interested and have it become theirs with you somehow getting paid off in the process. Unfortunately I think that will be a hard sell because Microchip probably peceives little demand for something better than C. Hence point that started all this. It will take a lot of users bitching and moaning about C before the likes of Microchip will pay any attention and try to provide something better. And that can't happen until people widely agree that C sucks. > Yes there are things I really hate about C but I really don't want to be > tied into just implementing a PASCAL compiler - I want to do better. > > I'll make you an offer, if you want to produce a free PASCAL compiler > for the 16 series, I'll let you use my XCASM assembler as a back end > free of charge provieded it is tied to the compiler so that it can't be > used as a standalone tool. Creating a new language for embedded programming, but also useful for general programming, is actually something on my list of fun things to do. There are lots of other things on that list (like making a flat sheet of foam core fly, or at least glide in a controlled way), so my bandwidth for that is extremely limited. All I've done so far is jot down a few notes on syntax and constructs. What does the interface to the back end of your compiler look like? What language is it written in? What output files does it produce? Does it create debug records compatible with MPLAB so that you can do source level debugging in MPLAB? I already have the front end of a Pascal compiler since that's how my source to source translator works. The front end reads the input source and builds in-memory structures that define the program in a language-independent way. The front end then exits and the back end runs to write out the program definition in whatever output language that back end supports. SST has multiple front and back ends, and they can be independently chosen. In theory a back end could be created that drives your PIC code generator, but I'd need to know a lot more about it before getting any idea how much work that would be. I just checked, and the C back end of SST is about 8500 lines of code, for example. > I agree that the resulting code would not have been less efficient but I > disagree that "the compiler would not have been much harder to write". > The early C compilers didn't even deal with function prototypes. A lot > of time was wasted actually tracking down bugs that were the result of > passing the wrong type of parameter to a function. I just checked, and the Pascal front end to SST is 7500 lines of code plus another 750 line syntax defintion file. Together these not only define the syntax, parse it, and translate the code to language-independent data structures, but also perform all the type checking. For a competent software engineer setting out to write a whole new program on the scope of a compiler, I think less than 10000 lines qualifies as "not hard". ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist