... snip ...
Somebody forgot to preserve attributes for material they quoted.
What seem to be missing is that any interpreted/script language requires an interpreter, which by itself represents a large body of code, without the opportunity to pare it down to essentials.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
... snip ...
Obviously an incompetent customer. (or maybe very inexperienced.)
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
That's pretty impressive!
Again, I'm impressed. But I'd have to ask: - Kernel: why? - Tiny Basic: footprint?
We were forever optimising the code for space and speed; fairly often we'd have to add a feature and find a way of cramming it in. Later, when we also used the 8051, I remember being very impressed with PL/M and suggesting it to my boss and colleagues, and being greeted with derision... the footprint and the license fees were simply considered unnecessary (they were Macho Coders ;)). I'm genuinely curious - it would have been great to have used some better tools back then...
[And to contradict myself slightly from earlier: since getting into the H8, my gut feeling that a HLL, a suitable architecture, and good design practice could actually *improve* code size and speed over assembler has been confirmed.]Steve
FLEX OS demanded 8 kB of System RAM, but only about 4 kB of it was taken up by code; It also contained "System Disk Buffers", an area for printer spooling (including a disk record buffer), system stack space, and an area for "Transient Utilities", that could be run without disturbing applications that were running in "main" RAM, starting from $0000.
The ROM/EPROM was mainly used for a small disk bootstrap routine, and the serial I/O routines necessary for the boot command. The rest of the
2 kB space was used for "Monitor routines", such as Memory Examine/Change.Quite frankly: Because our client demanded it... :-) But it also made it easy to add new tasks, should that be necessary in the future.
Now I remember it was called A/Basic. It was a native compiler, that ran on a 6800 "development system" -- with two cassette decks. :-) It came with a programming editor, RtEdit, that was written in A/Basic. Everything ran in 8 kB of RAM. Later on, there came a version that ran under FLEX 6800.
Only some routines, such as printing conversion, the math packages, and the cassette I/O routines were called in from a library when necessary, the rest of the code was generated "on the fly". Of course, the optimization wasn't worth much bragging by today's standards, but it wasn't too bad either.
Yes, I agree. (Though I take every opportunity to program in assembler. :-))
-- http://www.flexusergroup.com/
Well said, that chap.
I've done many large assembler projects for CPUs for which we had no C compiler (TMS7000 was one, *after* it was EOL'ed - don't ask ;). It involved legacy hardware...). So, I wrote in C and hand-compiled.
With the TMS7000 project, incidentally, this paid off handsomely later when I managed to get the project (partially) updated to the H8 family, for which a compiler *was* available. But that's almost not the point - I'm a *very* firm believer in designing first, and coding later.
Steve
Did you know that 83.2% of all statistics are made up on the spot?
C will not be dead in 15-20 years. A higher proportion of application-level embedded software will be written in other languages (already today there is a noticeable proportion written in Java, and C++ is not uncommon when you have cheap 32-bit processors), but virtually all the low-level stuff will be in C and assembly. There is far too much momentum in this industry, and too many long-term projects for things to change fast.
avrgcc also lets you reserve registers, or use them as global variables permanently assigned to specific registers. But no C compiler will allow the sort of flexibility I could take advantage of in assembly (among other things, the Z register pair was dedicated to interrupt routines).
Could you please provide a pointer how to do this? I didn't find anything related.
Thank you!
Regards,
Phil
Quite right,mind you 500 bytes seems to be 3 times too big as well.
(Question 3 in the avrlibc FAQ, although I don't see why it should be a FAQ, since it is not something you should normally want to do.)
mvh.,
David
ese
ch
Flex has been ported to a 6809 implemented on a Xilinx Spartan 3 FPGA. I've tried it on my S3 kit and it works OK. It probably runs a lot faster than a real 6809, but I haven't checked it.
Leon
If you're referring to the implementation by John Kent in Australia (a member of the FLEX User Group), he recently wrote that the 6809 core is running with 12.5 MHz E-clock, corresponding to 50 MHz crystal frequency on a "real" 6809.
-- http://www.flexusergroup.com/
IMO, regester usage is _more_ flexible in a HLL because the compiler is much better at allocating registers than people are.
But you just said that avrgcc let you do that!
--
Grant Edwards grante Yow! Where's th' DAFFY
at DUCK EXHIBIT??
visi.com
mmm. This was done using the 'Reply' link at the bottom of the article. Maybe your efforts were not in vain.
Rocky
Good for you. Now you are on the way to becoming a civilized usenetter, in spite of googles efforts to thwart you! :-)
-- "The power of the Executive to cast a man into prison without formulating any charge known to the law, and particularly to deny him the judgement of his peers, is in the highest degree odious and is the foundation of all totalitarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Depends on the complexity of the MMI to control the TRIAC I guess. Softstart , 50+ / 60 Hz operation , variable sepeed etc.
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
You know what's funny? I bet the people who work on Google Groups saw your signature and likely saw you ranting about it and decided to fix it immediately :) .
-Isaac
... snip ...
I have been ranting about it for over a year. Are you saying that google fixed it at last? I don't use it, so I wouldn't know. I would love to retire that particular sig.
-- Some informative links: news:news.announce.newusers http://www.geocities.com/nnqweb/ http://www.catb.org/~esr/faqs/smart-questions.html http://www.caliburn.nl/topposting.html http://www.netmeister.org/news/learn2quote.html
If you only have a small amount of critical data, it's perfectly possible to keep track of it within registers (it requires a little extra discipline in the programming, and good naming conventions). If you have a lot of data moving in and out of different registers, then a compiler will make a better job since it is happier keeping dozens of allocations in its head without producing a maintainance nightmare.
avrgcc will let you dedicate *some* registers, but not ones that are essential to its code generator such as the Z register.
I should note that I wrote the assembly version before there was a decent C compiler available for the AVR (IAR's compiler existed, but was considered indecent due to the price and previous experiences with their dongles), while the later C version was written using ImageCraft's compiler. If I'd had the compiler at the time, I probably would not have written the assembly version in the first place.
Just for you, CB, a test done using the "Reply" link.
~Dave~
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.