Dave Hein said...
I believe that an ANSI standard C compiler could generate Spin bytecodes that would be as efficient as a Spin compiler for many applications. Of course, there will be cases where strict compliance to C will cause extra operations to be performed. A simple example would be the use of char versus unsigned char. Accessing a char would require a sign extension operation, whereas the unsigned char would not need the sign extension.
This is exactly my point. You can't skimp on these things just for the sake of efficency, and then just say "oh well, it's close enough for many applications - we never claimed it was 100% compliant".
Just imagine how annoyed you would be if you were a Propeller newcomer (and possibly also a C newcomer) who struck this particular incompatibility. After long nights of skull-sweat you finally get your program working under the interpreted C environment. Then you move the result to the compiled C environment (or the other way round) only to discover it no longer works - because one sign extends but the other doesn't. You may never be able to find the problem.
There are lots of opportunities in the definition of PMC for 'gotchas' like that (plus worse ones!) which a newcomer would be completely incapable of resolving. In many cases the C code they are working with may not be their own - e.g. they may have downloaded a standard C algorithm from the internet, or be working with an existing code base - and expect it to "just work". If the code is ANSI C, this is a perfectly reasonable expectation. In such cases, how would they even know where to begin looking?
An experienced programmer would probably be on the lookout for this type of thing when porting code between two different compilers made by different companies on two different platforms. But a newcomer using two tools integrated into the same development environment, for the same platform, and offered by the same company? Naturally they'd be spitting chips when they discovered it.
A newcomer might shrug off their anger and persevere with this "really keen new multiprocessing chip" they have shelled out their hard-earned money on. But a professional programmer would probably get a sinking feeling in the pit of their stomach. If they hadn't done so already, they would then read the PMC manual in forensic detail. When they did so they would be horrified at the amount of potential rework of their existing code base they are letting themselves in for, and would most likely discard the whole idea of using a Propeller in the new generation product they have just been asked to design.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
"repeat i from 0 to num" is not the same as "for (i = 0; i <= num; i++)" for negative values of num
and
"repeat i from 0 to -10 step -2" is not the same as "for (i = 0; i >= -10; i -= 2)"
repeat determines whether it will increment or decrement based on the initial start and end values.· The "step" value is multiplied times the initial increment value of +/- 1.· A step value of -2·will result in a loop increment of +2 in the above example.· Once you understand how the repeat is implemented it is pretty straightforward.· However, it does seem a little odd at first.
This is exactly my point. You can't skimp on these things just for the sake of efficency, and then just say "oh well, it's close enough for many applications - we never claimed it was 100% compliant".
Ross,
I agree with you.· The "silent" nonstandard features would drive a programmer crazy.· However, you may have misunderstood me.· A signed char would be accessed as ~byte[noparse][[/noparse]ptr] and an unsigned char would be byte[noparse][[/noparse]ptr].· The point is that using signed chars is less efficient than unsigned chars in Spin bytecode.
PMC must be standard compliant for the features it implements.· However, it doesn't have to implement everything.· Items such as double, goto·and function pointers might be things that aren't supported.· Of course, this would make porting some code more difficult.
Dave
Ross
There are a few useful features from converting C to Spin bytecodes -- It is a very compact code, and it would be compatible with the existing Spin code in the OBEX. A C compiler of this type would be useful to hobbyist who want to develop applications that work at the same level as current Spin programs.
I believe that an ANSI standard C compiler could generate Spin bytecodes that would be as efficient as a Spin compiler for many applications. Of course, there will be cases where strict compliance to C will cause extra operations to be performed. A simple example would be the use of char versus unsigned char. Accessing a char would require a sign extension operation, whereas the unsigned char would not need the sign extension.
I think the Prop I could get by with a cspin-like implementation. However, I believe that the Prop II will need real C development tools, such the Catalina C compiler. Parallax would have to officially support those type of develop tools to be taken seriously by development teams looking for the right processor for their project.
So, the real question for Parallax is whether it is worth the effort to provide a C-to-Spin development tool for the short term knowing that they will need a full-blown C development system for the long term.
Dave
Just to be pedantic, "char" in Standard C does not necessarily mean "signed char." The choice is up to the implementation. If you mean "signed char," you have to write "signed char." Our compilers use "unsigned char" for "char" and it has never cause a problem.
It's relatively easy to have mix LMM and bytecode. You will need two Cog, one for the LMM kernel and one for the bytecode, but so far, there does not seem to be too much ROI for us to invest in this yet. Frankly, there is no way that it will cost Parallax LESS to write this PMC themselves than to partner with someone else to do a proper job.
This was Dave's example, not mine. But it is a fair example. PMC proposes to make everything signed - presumably to save the extra few bytcodes required to implement both signed and unsigned types.
So if I say "unsigned char" what do I get? Either I get a program which won't compile (and if I'm a newbie I probably won't understand why - after all, a char is a char, isn't it?). If on the other hand the compiler silently ignores my "unsigned" request and makes the character type signed, then the program will compile okay but will then fail in obscure ways that (being a newbie) I won't understand or be able to fix.
Either one is a recipe for disaster.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Good discussion- and very timely- I think the Propeller is at a critical point where a lot of more serious people are thinking about it. Many "serious" people don't like to learn a new language, so support for ANSI C and complete toolchains are important. Ross's Catalina fits the bill nicely.
Oh- and just to make this thread fun- here's something interesting I found with ViewPort:
The command:
"repeat n from 0 to 10"
actually counts up to 11!
If you monitor the "n" variable in another cog, you'll occasionally see the number 11.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Spend a couple of days seeing England and here is a 6 page thread. I have not read everyone's posts in detail, but here are my thoughts to Parallax. I am disapointed by the lack of progress in the Porpeller Tool. I also dream of a Propeller II with its tool. If the education market needs C, why not just use one of the two existing C's for the Propeller? I have programed in C, as well as many other languages over the last 45 years, but have not felt a need to go beyond Spin and PASM for the Propeller. I cannot compare ImageCraft C to Catalina. Probably the deciding factor to pick one of these two would be the development environment.
I'll add my vote for the Propeller Tool party. I'd also like to mention that any tool development really needs to target Windows, Linux, and OS X. One of the main joys of working with the Chameleon is that I can develop code for both chips (Propeller and AVR Mega 368) on my iMac. I don't mean to be heretical, but one of the first things that got me started with the Arduino line was their IDE. I like the ability to use Processing to get my iMac talking to the AVR chip using Arduino's bootloader and all the other niceties their system provides. If Parallax could have such an IDE in place by the time the Propeller II is ready. Who needs more C, really?
Now my code-developing happiness would be complete if Hanno would port Viewport to OS X.
I'd like to mention something about targets for the "it has to be faster than Spin" crowd. Firstly, C is faster than other languages mostly because it is a crappy language that doesn't do memory management, array bound checking, type checking, or a lot of other stuff you can take for granted in a real high level language; it's basically short-form PDP-11 assembly language with a lot of braces and parentheses. So on most micros it generates code that is extremely small and efficient because it isn't bloated up with all kinds of convenience features like buffer overrun protection.
But the Prop is not a PDP-11, which is why we are having this discussion. There are basically five possible targets for an hypothetical C compiler on the Prop:
1. Translate to Spin. This will not work unless you seriously upgrade Spin first. Like it or not, GOTO is a part of C. Multi-dimensional arrays are part of C. C-heads may forgive you for omitting a feature that is too bloaty to be implemented on the micro, but they're not going to forgive you for omitting something that is useful, common, and easy to implement.
2. Spin bytecode. It will be about as efficient and run only as fast as Spin, but will be more familiar to the people whose brains have been poisoned by too much exposure to C and satisfy those silly curriculum requirements that demand C. And yes, you can and should implement GOTO, because it is possible and very definitely a part of C. Spin is about forcing you to do certain things like indentation and control structs right; C is about letting you get into just as much trouble as you want.
3. LMM. This looks great at first because it's much faster than Spin, but it's also much more bloaty, taking two to four times the Hub RAM to do the same thing as Spin bytecode. Some of the stuff we've come to take for granted, like reading FAT filesystems, just won't fit in 32K with LMM. And for much of that code the high speed isn't needed, making it a pure waste.
4. PASM. Cogs have only 512 instructions, and C maps very poorly to them. For anything more complex than blinking an LED you will run out of Cog RAM before you know what hit you. Total waste of time.
5. LMM paged or read from external memory. Here you could solve the memory limit problem and get faster than Spin performance, but you lose a lot of I/O pins and get tied to very specific architectures. I don't think this is a practical target for a generic tool. That's an option that needs to be marketed with whole systems that can support the external memory scheme. Sort of like what some people are already selling.
Of these choices, the only one that makes any sense for inclusion in the proptool is Spin bytecode. By design, that pretty much IS the low-level language of the Propeller for business logic. It is the only option that isn't seriously limited in some major way compared to Spin itself. And it should be possible to implement such a C which includes all the little things that are strikingly absent from Spin or confusingly different so that it will be comfortable to people who think "for(n = 0; n < 10; n++) ;" is more readable than "repeat n from 0 to 9".
Actually, you don't really have to call it C anyway. Just say it has a C-like syntax.
I think if the Parallax programmers weren't Pascal programmers then SPIN would already have a C-like syntax instead of a Pascal-like syntax and life would be better.
Total agreement!
Rayman said...
But, I think the main advantage of this thing is that it used the ROM Spin interpreter (if I'm understanding it right).
So, just like CSPIN, you program in something like C and that get translated into SPIN byte codes.
This has the advantage of being able to make the most efficient use of RAM, even though it's probably slower and more limited that ICC or Catalina.
Being able to use the SPIN and assembly drivers AS IS, is a huge benefit too...
These are the important points and the key benefits.
JT Cook said...
But since then I have worked on other projects using other micros which have native C and ASM support built into the tools. Since then it has been hard (for me) to come back to the Propeller chip because of the SPIN language. Now I don't think there is anything wrong with SPIN, but after being able to program with C on other micros it is hard to go back to a specialized language that I have to refresh my memory with. Now with that said I still love the Propeller, and for someone like me who uses it to make video games, it is a very capable micro. There are other C options like Image Craft C and Catalina C (the later of which I would like to check out if I get some time), but a built in version of C that in the Propeller tools will be awesome!
Good. I am not alone.
ImageCraft said...
The age of non-standard C is over.
***
If you want to do it right, spec a new spin'ish byte code and compile Standard C into that.
ImageCraft said...
Non-Standard C no longer has a place in the industry. Rabbit Semiconductor tried that tack 10 years ago with Dynamic C and that is always one of its Achilles Heels. It is seldom seen as an advantage.
ImageCraft said...
there does not seem to be too much ROI for us to invest in this yet.
@ImageCraft
You are the man for the standard C-compiler! Make your work ready. You went only half the way with your compiler. The minimum you have to do is a "directive" for your fcache. I said this almost two years ago. I bought your compiler in the hope that there would be any movements.
ROI: I think that was your problem from the beginning. Thus you did only the absolutely most necessary things. In my opinion that was not enough. And you heard only the LMM promoters.
potatohead said...
Do it. Have a directive for C=>PASM, and that builds code that goes on a COG, just like a DAT PASM block does. The rest of the code is byte code, making the most of the on-chip interpreter, and let the programmers sort it out like programmers will. Don't forget a full on assembly environment too, just like you would find in any other C environment. Let them figure out how to best apply those things. That's what C is about. The programmer gets to do really stupid things, and really powerful things. SPIN + PASM is managed to keep people outta trouble, and look at all the stuff done to circumvent that. This is the chance to put all that to bed, not devaluing the SPIN + PASM at all!
RossH said...
...
PMC proposes to make everything signed - presumably to save the extra few bytcodes required to implement both signed and unsigned types.
So if I say "unsigned char" what do I get? Either I get a program which won't compile (and if I'm a newbie I probably won't understand why - after all, a char is a char, isn't it?). If on the other hand the compiler silently ignores my "unsigned" request and makes the character type signed, then the program will compile okay but will then fail in obscure ways that (being a newbie) I won't understand or be able to fix.
...
Ross,
The PMC proposal doesn't support the unsigned keyword, but char and short would be unsigned by default, and int/long would be signed.· This is the same as Spin, and it does save a few extra bytecodes this way.· The PMC proposal does support the signed keyword, which would allow for signed char and signed short.
If you say "unsigned char" I assume you would get a compile error.· It seems like it would be trivial for PCM to support the unsigned keyword, so I don't understand why the spec doesn't support it.· Now unsigned int would take a little more work to support -- mostly in ">" and "<" compares and in multiplication and division.· Spin and PASM have a native unsigned shift right, so that should be easy.
This thread page does a good job of summarizing the opinions and issues.· I think localroger's list of possible targets is excellent.· I would rephrase them as:
1. C to Spin
2. C to bytecodes
3. LMM
4. PASM
5. XMM
6. Extended Spin
7. Basic
I added the extra options of extended spin and Basic, since a lot of people think·those are good ideas·also.· Parallax has a tough job figuring out which way to go.· Their decision will ultimately affect the direction of the company in the future.· There are propeller users that support at least one of the·7 options, and some people like more than one option.
If I were Parallax I woud do them all!· This way they satisfy almost everyone, and ultimately it will allow them to sell more Prop chips.· Doing it all may sound like a huge undertaking, but there are already solutions out there -- Catalina C, ImageCraft, cspin, ctospin, BST, PropBasic, etc.· Parallax would need to officially support a solution for each of the 7 options, and either collaborate on the development, or take it over entirely.·· Of course, those are business decisions that only Parallax can make.
And I agree with Ross and some others that PMC should be fully standards compliant with the caveat that it may not support certain features, such as the double type.
Dave
I wonder how many remember this article published April 1, 1991 in Computerworld? (from comp.sys.prime)
CREATORS ADMIT UNIX, C HOAX
In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate April Fools prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:
"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had just started working with an early release of Pascal from Professor Nicklaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading `Bored of the Rings', a hilarious National Lampoon parody of the great Tolkien `Lord of the Rings' trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. Then Dennis and Brian worked on a truly warped version of Pascal, called `A'. When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:
To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We actually thought of selling this to the Soviets to set their computer science progress back 20 or more years. Imagine our surprise when AT&T and other US corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960's technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. In any event, Brian, Dennis and I have been working exclusively in Pascal on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion and truly bad programming that have resulted from our silly prank so long ago."
Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C and Turbo C++, stated they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and had to postpone a hastily convened news conference concerning the fate of the RS-6000, merely stating `VM will be available Real Soon Now'. In a cryptic statement, Professor Wirth of the ETH institute and father of the Pascal, Modula 2 and Oberon structured languages, merely stated that P. T. Barnum was correct.
In a related late-breaking story, usually reliable sources are stating that a similar confession may be forthcoming from William Gates concerning the MS-DOS and Windows operating environments. And IBM spokesman have begun denying that the Virtual Machine (VM) product is an internal prank gone awry.
{COMPUTERWORLD 1 April}
{contributed by Bernard L. Hayes}
4. PASM. Cogs have only 512 instructions, and C maps very poorly to them. For anything more complex than blinking an LED you will run out of Cog RAM before you know what hit you. Total waste of time.
496 instructions --> one blinking LED
My conclusion:
LMM --> 8000 instruction -> 16 blinking LED's
Is that a fair discussion???????
Why someone (Bob Anderson, I think) made AAC (Augmented Assembly Code). For an blinking LED????
Dave Hein: I think there are additional options that admittedly would be harder to implement but result in a "best of both" kind of solution as far as speed and size. They are C to bytecodes & PASM, Spin to bytecodes & PASM, and BASIC to bytecodes & PASM. When I say "bytecodes & PASM" I mean a compiler that is targetting the Propeller's whole architecture. Utilizing all 8 cogs, as needed, implicitly, not just explicitly. It's a tricky problem, that would take some serious architecting, but I think it's possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Roy Eltham said...
Dave Hein: I think there are additional options that admittedly would be harder to implement but result in a "best of both" kind of solution as far as speed and size. They are C to bytecodes & PASM, Spin to bytecodes & PASM, and BASIC to bytecodes & PASM. When I say "bytecodes & PASM" I mean a compiler that is targetting the Propeller's whole architecture. Utilizing all 8 cogs, as needed, implicitly, not just explicitly. It's a tricky problem, that would take some serious architecting, but I think it's possible.
I wasn't very clear on labelling items 3, 4 and 5.· These items have an implied "C to " before it.· So what I really meant to say is as follows:
1. C to Spin - Standard C converted to the Spin language, compatible with current Spin Objects
2. C to bytecodes - Standard C converted to Spin bytecodes, compatible with current Spin Objects
3. C to PASM with LMM - C compiler using the large memory model within the Prop's 32K RAM
4. C to PASM within a COG - C compiler using the COGs memory for program and variables
5. C to PASM with XMM - C compiler uses additional RAM through I/O port
6. Extended Spin - Spin tool with a·pre-processor tht compiles to bytecodes and PASM
7. Basic - Basic compiler that compiles to PASM (and maybe spincodes)
As you mentioned, item 4 can be incorporated into the other items.· All of the options should allow for inserting PASM the way the spin tools currently does.· In addition, they should be able to compile higher level source, such as C, Spin or Basic into PASM that is targeted for a COG.· I spent a couple of weeks prototyping extensions to spin tht I call xspin.· It includes a C preprocessor and the capability to generate COG code using special sections named CPUB, CPRI and CDAT.
I think Parallax can support all of the options listed above with a minimal drain on their resources.· It would require a tighter coordination iwth the various adhoc projects that are being developed within the Prop user community.
Dave ·
jazzed, I think w8an knew that. (I remember reading that article in Computerworld when it was first published in 1991. Almost 20 years later the joke remains current.)
I have been following this thread, but I have held back from commenting for several reasons.
1) I know almost nothing about C (never had a need to learn it)
2) I don't want to come off as promoting PropBasic.
But I want to make several points. First I believe that PropBasic generates fairly tight code, and I would assume that a decent C compiler would generate at least as tight code.
PropBasic can compile to native PASM or to LMM (HUB)·PASM. I can tell you that 496 instruction in native PASM can do alot more than just blink an LED. You can write complete video drivers in PropBasic. That is something that you will never do with any other option (LMM, ByteCodes, etc.). And that really is the only reason I decided to generate native code.
Having LMM as an option allows you to write much larger programs at the expense of speed. LMM is about 5 times slower. Except for a few instructions·the LMM code is pretty much the same. JMP, CALL, RET, etc do take multiple instructions. Oh, and I'm talking about HUB LMM not code pulled external memory.
At first I looked at translating BASIC to spin. But the speed is really poor, and I didn't want to have to make excuses for not being able to use the·full·power of propeller chip (video drivers, etc). The answer·"Oh, you need to write PASM code, AND run it·in a seperate COG to do that" doesn't put your compiler in a good light. Plus it doesn't impress anyone when you can only toggle a pin at kilohertz speed (without using a counter).
To me the issue is...Is this 'C' language for schools or for industry ?
For schools, a C to spin converter is probably the easiest way. But I cannot see any professional in the electronics industry using it (I may be wrong).
Anyway that is my view.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
localroger said...
jazzed, I think w8an knew that. (I remember reading that article in Computerworld when it was first published in 1991. Almost 20 years later the joke remains current.)
Whatever. People who like C know how to deal with it's problems. What language do you actually prefer besides ASM?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
jazzed, my experience is that most applications have two layers of code which need to be handled differently. The business logic, which is 80% or more of your LOC, does not need to be high speed because it is presenting human user interfaces and monitoring relatively infrequent events. For that you want a language that enforces array and buffer limits, does automatic memory management with garbage collection, and has powerful, glitch-free native math and string functions. In my industry that means VB (once it might have meant QuickBasic) or Pascal.
Then you have things that need to be fast -- high speed I/O drivers, algorithms that sort and pick through large amounts of data, certain CPU hungry math algorithms. That's really the kind of code C is for, but you will probably be able to write better code than the C compiler and it's such a small part of the project it won't be much more work, doing it in ASM. (There is a persistent myth that C compilers are smarter than human ASM programmers and write tighter code. I'm a human ASM programmer, and this is not true. I have looked at enough trainwreck C object code to be very sure of this.)
There are ways to coax the C compiler into writing code that isn't a trainwreck in most situations, but as soon as you use those techniques (1) you are no longer writing standard portable C code and (2) you have probably invested as much work learning the ins and outs of the C environment as you would have in learning the environment's ASM, which is a surer route to a dependable result.
That said, for PC level work I'd probably use a more standard tool like C instead of the increasingly fragmented and weird x86 assembler, but most of what I do is embedded and the asm environment is stable and you get very noticeably better results with asm. I am frankly trying to move away from working with PC's at all by leveraging the increasingly powerful embedded controllers to do things like presenting the user interface through a web browser instead of a native application (which is why I'm here).
Bean, I was obviously being a bit facetious with the blinking LED remark, but the situation is pretty bad. It's true that with PASM you can do as much in 2Kbytes as you could in 4 or more on a more normal CPU, but that also requires being carefully aware of certain PASM tricks, like creative use of the flags and condition field. While you might be able to write "a" video driver in a compiled language you won't be able to write a very good one, because that would require careful management of cycle timing. Your result will probably be larger and slower than what a careful PASM programmer could get, which becomes a problem fast with code of any complexity.
I like LMM but the problem with using it for business logic is that it's 2 to 4 times larger than bytecode that does the same thing, which brings you to the same problem in Hub RAM, which is already seriously limited for some applications at 32K. Yes, you can do a demo that shows the Prop generating TV or reading a SD card or implementing a TCP/IP stack, but I need an environment that can do all three of those things at the same time. That requires carefully thinking of what to do in bytecode and what to do in PASM and managing every byte carefully. Yes, you don't need that level of control for every project but you get there pretty quickly, especially if you're using some of the powerful OBEX objects to do fancy stuff.
One thing that struck me about the Propeller is how closely its architecture reflects my own experience on the split between business and driver logic; you have PASM code which has to be small but can be very fast indeed, with a lot of totally uncompilable techniques that would be familiar to someone who's dabbled in Atari 2600 programming, and you've got Spin which is much slower but also more compact and convenient for the stuff that doesn't have to be that fast. That's a perfect split for real applications; it's how I was writing apps for DOS back in 1988, in a mix of compiled Basic and assembly language that was very powerful and reliable.
[noparse]:)[/noparse] that's a fine positioning statement for this chip, and I agree.
This is why I favor a C environment that goes right to the byte code, and one where a directive can be used to build PASM, finally allowing users to just put assembly right in there, directly.
That's going to be potent on all levels, reinforcing a lot of good things, not short changing the processor, and being actually useful. I have given the educational goal some thought, and it's a loser to me, if not practical in addition to simply being possible.
I will promote PropBasic for you...It's a great tool.
It is worthy just as a way to help people learn pasm.
If a nice guidebook for pasm is ever written, it should feature PropBasic
as a preferred learning tool.
localroger
You are of course correct, asm is the way to go to squeeze all the potential
from a relatively slow and memory deprived controller. If you are limited to using
only C, Basic or whatever other language and can't code in asm then there are
lots of projects you just can't create...better take a crash course in asm on whatever
controller you use.
Asm is not really hard, it is just tedious compared to something like C, but it is actually
easier to learn and to use. (at least if there is a proper manual!)
Anyone that can make out a grocery list and plan out a trip to town to run several errands
can learn to use asm.
localroger: I have to take a little bit of issue with the idea that a C compiler can't produce good asm. That a human asm coder can always produce better code. While this may be true for some compilers, it's not universal. Especially depending on the CPU target. My experiences with this are mainly with Visual C/C++ 2005/2008 and the Intel C/C++ compiler targetting x86 platforms. I have looked at the asm code they produce pretty extensively, and it's very efficient and often does things a human would have had a hard time doing by hand. Of course this hasn't always been true, older versions (especially VC6 and prior) would often produce questionable results. Also in regards to "coaxing" the compiler to produce good asm, I used to do this kind of thing all the time in my work, but it's largely wasted effort with recent VC 2005/2008. I've personally done several tests with and without coaxing tricks and the resultant asm was the same regardless and it was the desired asm result. Just so you know where I am coming from, I program computer and video games, it took us a long time to switch from asm only to mixed C and asm, and then to C++ with asm to finally just C++. Seriously, most games for PC, PS3, and XBox360 are written in C++ (some do contain tiny bits of asm, but that's mostly because of an old school coder being involved).
Anyway, for the Propeller, hand written PASM is likely to always be the most performant, luckily it's pretty easy to do. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
@Roy Eltham I would agree that the newer x86 chips have gotten so weird that you almost need the compiler to sort through all the little timing gotchas and register management situations. I have never written a line of ASM for a Windows program. But then modern PC's are so fast that VB6 is fast enough to do what you need C or ASM for on lesser platforms. I have done a lot of embedded work (including building my own development system) for two generations of the same box, starring a 80186 and 80386sx. The 80186 firmware was *awful* doing things like repeating the same offset calculation involving two MULs over and over and over again while accessing different data within the same object. The 80386 flat model firmware (largely compiled from the same source) is a lot better, but then I'd told the firmware maintainer about what I found reverse assembling the 80186 version so that may have moved them to change some compiler switches.
Sorry my ignorance BUT "C" has giving more problems to Micros/CPU's in its beginning as POSITIVE enforces.
That some of CPU/Micro Manufacturer switched to simpler INSTRUCTIONS set to met only "C" needs - BIG mistake.
Now we have Memory hungry CPU's that instead of WISE Instruction SET have only simple ones. That give endless "C" programs with endless loops.
IT was very bad decisions from manufacturers side to give "C" that position.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
-Phil
This is exactly my point. You can't skimp on these things just for the sake of efficency, and then just say "oh well, it's close enough for many applications - we never claimed it was 100% compliant".
Just imagine how annoyed you would be if you were a Propeller newcomer (and possibly also a C newcomer) who struck this particular incompatibility. After long nights of skull-sweat you finally get your program working under the interpreted C environment. Then you move the result to the compiled C environment (or the other way round) only to discover it no longer works - because one sign extends but the other doesn't. You may never be able to find the problem.
There are lots of opportunities in the definition of PMC for 'gotchas' like that (plus worse ones!) which a newcomer would be completely incapable of resolving. In many cases the C code they are working with may not be their own - e.g. they may have downloaded a standard C algorithm from the internet, or be working with an existing code base - and expect it to "just work". If the code is ANSI C, this is a perfectly reasonable expectation. In such cases, how would they even know where to begin looking?
An experienced programmer would probably be on the lookout for this type of thing when porting code between two different compilers made by different companies on two different platforms. But a newcomer using two tools integrated into the same development environment, for the same platform, and offered by the same company? Naturally they'd be spitting chips when they discovered it.
A newcomer might shrug off their anger and persevere with this "really keen new multiprocessing chip" they have shelled out their hard-earned money on. But a professional programmer would probably get a sinking feeling in the pit of their stomach. If they hadn't done so already, they would then read the PMC manual in forensic detail. When they did so they would be horrified at the amount of potential rework of their existing code base they are letting themselves in for, and would most likely discard the whole idea of using a Propeller in the new generation product they have just been asked to design.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/18/2010 5:51:13 AM GMT
"repeat i from 0 to num" is not the same as "for (i = 0; i <= num; i++)" for negative values of num
and
"repeat i from 0 to -10 step -2" is not the same as "for (i = 0; i >= -10; i -= 2)"
repeat determines whether it will increment or decrement based on the initial start and end values.· The "step" value is multiplied times the initial increment value of +/- 1.· A step value of -2·will result in a loop increment of +2 in the above example.· Once you understand how the repeat is implemented it is pretty straightforward.· However, it does seem a little odd at first.
I agree with you.· The "silent" nonstandard features would drive a programmer crazy.· However, you may have misunderstood me.· A signed char would be accessed as ~byte[noparse][[/noparse]ptr] and an unsigned char would be byte[noparse][[/noparse]ptr].· The point is that using signed chars is less efficient than unsigned chars in Spin bytecode.
PMC must be standard compliant for the features it implements.· However, it doesn't have to implement everything.· Items such as double, goto·and function pointers might be things that aren't supported.· Of course, this would make porting some code more difficult.
Dave
Just to be pedantic, "char" in Standard C does not necessarily mean "signed char." The choice is up to the implementation. If you mean "signed char," you have to write "signed char." Our compilers use "unsigned char" for "char" and it has never cause a problem.
It's relatively easy to have mix LMM and bytecode. You will need two Cog, one for the LMM kernel and one for the bytecode, but so far, there does not seem to be too much ROI for us to invest in this yet. Frankly, there is no way that it will cost Parallax LESS to write this PMC themselves than to partner with someone else to do a proper job.
This was Dave's example, not mine. But it is a fair example. PMC proposes to make everything signed - presumably to save the extra few bytcodes required to implement both signed and unsigned types.
So if I say "unsigned char" what do I get? Either I get a program which won't compile (and if I'm a newbie I probably won't understand why - after all, a char is a char, isn't it?). If on the other hand the compiler silently ignores my "unsigned" request and makes the character type signed, then the program will compile okay but will then fail in obscure ways that (being a newbie) I won't understand or be able to fix.
Either one is a recipe for disaster.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/18/2010 8:42:04 AM GMT
Oh- and just to make this thread fun- here's something interesting I found with ViewPort:
The command:
"repeat n from 0 to 10"
actually counts up to 11!
If you monitor the "n" variable in another cog, you'll occasionally see the number 11.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
John Abshier
Now my code-developing happiness would be complete if Hanno would port Viewport to OS X.
But the Prop is not a PDP-11, which is why we are having this discussion. There are basically five possible targets for an hypothetical C compiler on the Prop:
1. Translate to Spin. This will not work unless you seriously upgrade Spin first. Like it or not, GOTO is a part of C. Multi-dimensional arrays are part of C. C-heads may forgive you for omitting a feature that is too bloaty to be implemented on the micro, but they're not going to forgive you for omitting something that is useful, common, and easy to implement.
2. Spin bytecode. It will be about as efficient and run only as fast as Spin, but will be more familiar to the people whose brains have been poisoned by too much exposure to C and satisfy those silly curriculum requirements that demand C. And yes, you can and should implement GOTO, because it is possible and very definitely a part of C. Spin is about forcing you to do certain things like indentation and control structs right; C is about letting you get into just as much trouble as you want.
3. LMM. This looks great at first because it's much faster than Spin, but it's also much more bloaty, taking two to four times the Hub RAM to do the same thing as Spin bytecode. Some of the stuff we've come to take for granted, like reading FAT filesystems, just won't fit in 32K with LMM. And for much of that code the high speed isn't needed, making it a pure waste.
4. PASM. Cogs have only 512 instructions, and C maps very poorly to them. For anything more complex than blinking an LED you will run out of Cog RAM before you know what hit you. Total waste of time.
5. LMM paged or read from external memory. Here you could solve the memory limit problem and get faster than Spin performance, but you lose a lot of I/O pins and get tied to very specific architectures. I don't think this is a practical target for a generic tool. That's an option that needs to be marketed with whole systems that can support the external memory scheme. Sort of like what some people are already selling.
Of these choices, the only one that makes any sense for inclusion in the proptool is Spin bytecode. By design, that pretty much IS the low-level language of the Propeller for business logic. It is the only option that isn't seriously limited in some major way compared to Spin itself. And it should be possible to implement such a C which includes all the little things that are strikingly absent from Spin or confusingly different so that it will be comfortable to people who think "for(n = 0; n < 10; n++) ;" is more readable than "repeat n from 0 to 9".
These are the important points and the key benefits.
Good. I am not alone.
@ImageCraft
You are the man for the standard C-compiler! Make your work ready. You went only half the way with your compiler. The minimum you have to do is a "directive" for your fcache. I said this almost two years ago. I bought your compiler in the hope that there would be any movements.
ROI: I think that was your problem from the beginning. Thus you did only the absolutely most necessary things. In my opinion that was not enough. And you heard only the LMM promoters.
That was my opinion from the beginning.
The PMC proposal doesn't support the unsigned keyword, but char and short would be unsigned by default, and int/long would be signed.· This is the same as Spin, and it does save a few extra bytecodes this way.· The PMC proposal does support the signed keyword, which would allow for signed char and signed short.
If you say "unsigned char" I assume you would get a compile error.· It seems like it would be trivial for PCM to support the unsigned keyword, so I don't understand why the spec doesn't support it.· Now unsigned int would take a little more work to support -- mostly in ">" and "<" compares and in multiplication and division.· Spin and PASM have a native unsigned shift right, so that should be easy.
This thread page does a good job of summarizing the opinions and issues.· I think localroger's list of possible targets is excellent.· I would rephrase them as:
1. C to Spin
2. C to bytecodes
3. LMM
4. PASM
5. XMM
6. Extended Spin
7. Basic
I added the extra options of extended spin and Basic, since a lot of people think·those are good ideas·also.· Parallax has a tough job figuring out which way to go.· Their decision will ultimately affect the direction of the company in the future.· There are propeller users that support at least one of the·7 options, and some people like more than one option.
If I were Parallax I woud do them all!· This way they satisfy almost everyone, and ultimately it will allow them to sell more Prop chips.· Doing it all may sound like a huge undertaking, but there are already solutions out there -- Catalina C, ImageCraft, cspin, ctospin, BST, PropBasic, etc.· Parallax would need to officially support a solution for each of the 7 options, and either collaborate on the development, or take it over entirely.·· Of course, those are business decisions that only Parallax can make.
And I agree with Ross and some others that PMC should be fully standards compliant with the caveat that it may not support certain features, such as the double type.
Dave
CREATORS ADMIT UNIX, C HOAX
In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie and Brian Kernighan admitted that the Unix operating system and C programming language created by them is an elaborate April Fools prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:
"In 1969, AT&T had just terminated their work with the GE/Honeywell/AT&T Multics project. Brian and I had just started working with an early release of Pascal from Professor Nicklaus Wirth's ETH labs in Switzerland and we were impressed with its elegant simplicity and power. Dennis had just finished reading `Bored of the Rings', a hilarious National Lampoon parody of the great Tolkien `Lord of the Rings' trilogy. As a lark, we decided to do parodies of the Multics environment and Pascal. Dennis and I were responsible for the operating environment. We looked at Multics and designed the new system to be as complex and cryptic as possible to maximize casual users' frustration levels, calling it Unix as a parody of Multics, as well as other more risque allusions. Then Dennis and Brian worked on a truly warped version of Pascal, called `A'. When we found others were actually trying to create real programs with A, we quickly added additional cryptic features and evolved into B, BCPL and finally C. We stopped when we got a clean compile on the following syntax:
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
To think that modern programmers would try to use a language that allowed such a statement was beyond our comprehension! We actually thought of selling this to the Soviets to set their computer science progress back 20 or more years. Imagine our surprise when AT&T and other US corporations actually began trying to use Unix and C! It has taken them 20 years to develop enough expertise to generate even marginally useful applications using this 1960's technological parody, but we are impressed with the tenacity (if not common sense) of the general Unix and C programmer. In any event, Brian, Dennis and I have been working exclusively in Pascal on the Apple Macintosh for the past few years and feel really guilty about the chaos, confusion and truly bad programming that have resulted from our silly prank so long ago."
Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C and Turbo C++, stated they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and had to postpone a hastily convened news conference concerning the fate of the RS-6000, merely stating `VM will be available Real Soon Now'. In a cryptic statement, Professor Wirth of the ETH institute and father of the Pascal, Modula 2 and Oberon structured languages, merely stated that P. T. Barnum was correct.
In a related late-breaking story, usually reliable sources are stating that a similar confession may be forthcoming from William Gates concerning the MS-DOS and Windows operating environments. And IBM spokesman have begun denying that the Virtual Machine (VM) product is an internal prank gone awry.
{COMPUTERWORLD 1 April}
{contributed by Bernard L. Hayes}
My conclusion:
LMM --> 8000 instruction -> 16 blinking LED's
Is that a fair discussion???????
Why someone (Bob Anderson, I think) made AAC (Augmented Assembly Code). For an blinking LED????
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
Dave Hein: I think there are additional options that admittedly would be harder to implement but result in a "best of both" kind of solution as far as speed and size. They are C to bytecodes & PASM, Spin to bytecodes & PASM, and BASIC to bytecodes & PASM. When I say "bytecodes & PASM" I mean a compiler that is targetting the Propeller's whole architecture. Utilizing all 8 cogs, as needed, implicitly, not just explicitly. It's a tricky problem, that would take some serious architecting, but I think it's possible.
I wasn't very clear on labelling items 3, 4 and 5.· These items have an implied "C to " before it.· So what I really meant to say is as follows:
1. C to Spin - Standard C converted to the Spin language, compatible with current Spin Objects
2. C to bytecodes - Standard C converted to Spin bytecodes, compatible with current Spin Objects
3. C to PASM with LMM - C compiler using the large memory model within the Prop's 32K RAM
4. C to PASM within a COG - C compiler using the COGs memory for program and variables
5. C to PASM with XMM - C compiler uses additional RAM through I/O port
6. Extended Spin - Spin tool with a·pre-processor tht compiles to bytecodes and PASM
7. Basic - Basic compiler that compiles to PASM (and maybe spincodes)
As you mentioned, item 4 can be incorporated into the other items.· All of the options should allow for inserting PASM the way the spin tools currently does.· In addition, they should be able to compile higher level source, such as C, Spin or Basic into PASM that is targeted for a COG.· I spent a couple of weeks prototyping extensions to spin tht I call xspin.· It includes a C preprocessor and the capability to generate COG code using special sections named CPUB, CPRI and CDAT.
I think Parallax can support all of the options listed above with a minimal drain on their resources.· It would require a tighter coordination iwth the various adhoc projects that are being developed within the Prop user community.
Dave
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
1) I know almost nothing about C (never had a need to learn it)
2) I don't want to come off as promoting PropBasic.
But I want to make several points. First I believe that PropBasic generates fairly tight code, and I would assume that a decent C compiler would generate at least as tight code.
PropBasic can compile to native PASM or to LMM (HUB)·PASM. I can tell you that 496 instruction in native PASM can do alot more than just blink an LED. You can write complete video drivers in PropBasic. That is something that you will never do with any other option (LMM, ByteCodes, etc.). And that really is the only reason I decided to generate native code.
Having LMM as an option allows you to write much larger programs at the expense of speed. LMM is about 5 times slower. Except for a few instructions·the LMM code is pretty much the same. JMP, CALL, RET, etc do take multiple instructions. Oh, and I'm talking about HUB LMM not code pulled external memory.
At first I looked at translating BASIC to spin. But the speed is really poor, and I didn't want to have to make excuses for not being able to use the·full·power of propeller chip (video drivers, etc). The answer·"Oh, you need to write PASM code, AND run it·in a seperate COG to do that" doesn't put your compiler in a good light. Plus it doesn't impress anyone when you can only toggle a pin at kilohertz speed (without using a counter).
To me the issue is...Is this 'C' language for schools or for industry ?
For schools, a C to spin converter is probably the easiest way. But I cannot see any professional in the electronics industry using it (I may be wrong).
Anyway that is my view.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134
March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Then you have things that need to be fast -- high speed I/O drivers, algorithms that sort and pick through large amounts of data, certain CPU hungry math algorithms. That's really the kind of code C is for, but you will probably be able to write better code than the C compiler and it's such a small part of the project it won't be much more work, doing it in ASM. (There is a persistent myth that C compilers are smarter than human ASM programmers and write tighter code. I'm a human ASM programmer, and this is not true. I have looked at enough trainwreck C object code to be very sure of this.)
There are ways to coax the C compiler into writing code that isn't a trainwreck in most situations, but as soon as you use those techniques (1) you are no longer writing standard portable C code and (2) you have probably invested as much work learning the ins and outs of the C environment as you would have in learning the environment's ASM, which is a surer route to a dependable result.
That said, for PC level work I'd probably use a more standard tool like C instead of the increasingly fragmented and weird x86 assembler, but most of what I do is embedded and the asm environment is stable and you get very noticeably better results with asm. I am frankly trying to move away from working with PC's at all by leveraging the increasingly powerful embedded controllers to do things like presenting the user interface through a web browser instead of a native application (which is why I'm here).
I like LMM but the problem with using it for business logic is that it's 2 to 4 times larger than bytecode that does the same thing, which brings you to the same problem in Hub RAM, which is already seriously limited for some applications at 32K. Yes, you can do a demo that shows the Prop generating TV or reading a SD card or implementing a TCP/IP stack, but I need an environment that can do all three of those things at the same time. That requires carefully thinking of what to do in bytecode and what to do in PASM and managing every byte carefully. Yes, you don't need that level of control for every project but you get there pretty quickly, especially if you're using some of the powerful OBEX objects to do fancy stuff.
One thing that struck me about the Propeller is how closely its architecture reflects my own experience on the split between business and driver logic; you have PASM code which has to be small but can be very fast indeed, with a lot of totally uncompilable techniques that would be familiar to someone who's dabbled in Atari 2600 programming, and you've got Spin which is much slower but also more compact and convenient for the stuff that doesn't have to be that fast. That's a perfect split for real applications; it's how I was writing apps for DOS back in 1988, in a mix of compiled Basic and assembly language that was very powerful and reliable.
This is why I favor a C environment that goes right to the byte code, and one where a directive can be used to build PASM, finally allowing users to just put assembly right in there, directly.
That's going to be potent on all levels, reinforcing a lot of good things, not short changing the processor, and being actually useful. I have given the educational goal some thought, and it's a loser to me, if not practical in addition to simply being possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I will promote PropBasic for you...It's a great tool.
It is worthy just as a way to help people learn pasm.
If a nice guidebook for pasm is ever written, it should feature PropBasic
as a preferred learning tool.
localroger
You are of course correct, asm is the way to go to squeeze all the potential
from a relatively slow and memory deprived controller. If you are limited to using
only C, Basic or whatever other language and can't code in asm then there are
lots of projects you just can't create...better take a crash course in asm on whatever
controller you use.
Asm is not really hard, it is just tedious compared to something like C, but it is actually
easier to learn and to use. (at least if there is a proper manual!)
Anyone that can make out a grocery list and plan out a trip to town to run several errands
can learn to use asm.
Anyway, for the Propeller, hand written PASM is likely to always be the most performant, luckily it's pretty easy to do. [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Sorry my ignorance BUT "C" has giving more problems to Micros/CPU's in its beginning as POSITIVE enforces.
That some of CPU/Micro Manufacturer switched to simpler INSTRUCTIONS set to met only "C" needs - BIG mistake.
Now we have Memory hungry CPU's that instead of WISE Instruction SET have only simple ones. That give endless "C" programs with endless loops.
IT was very bad decisions from manufacturers side to give "C" that position.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Maybe few asm coders could best the compiler at what it does but the asm gurus that created the compiler sure could.
If you want a good intro to x86 asm get Jeff Duntemann's 3rd edition of Assembly Language Step By Step
www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks&field-keywords=Jeff+Duntemann&x=8&y=16