What it really shows is increment is a special case and frequent enough in real life to optimise specifically. A more realistic test might be how many additions of a certain value in a particular time. But then we're into all sorts of problems in fair comparisons because some values fare better than others and that varies from VM to VM.
If we wanted we could even add specific bytecode which performs a particular task to bump the ratings up. I'm sure that happens from good intent anyway as people see different things they would optimise. I think it only becomes unscrupulous when optimising in order to achieve a good benchmark score.
The other problem of benchmarking is comparing like with like, something meant for bit-twiddling is likely to perform worse at floating point than something meant for floating point and vice-versa.
It was interesting to read the comments on fast square rooting in a another thread. I don't think I've used square root that many times ( and never on a micro ) so for me that would go way down the priority list for fast execution, same with multiply, divide, mod and anything floating point.
Floating point is not that useful (I already said that!) in a uC but some few times you may need it. Multiply and divide are in that order useful but as you know there are plenty of options using shifts and adds or subs to achieve similar results. The idea of the test was another one...
Now, I have to close the circle and finish the assembler.
Roll-up, roll-up ! Hold on tight and watch in amazement as bytecode executes before your very eyes. Be incredulous at the magnificence of the variable contents viewer. Gasp in awe and wonder at the power of the beast as each opcode perambulates by.
Second major milestone reached - One LCC VM which actually runs. You'll need Id Software's Quake 3 port of LCC ( instructions in ReadMe.Htm ). Install the three required files and all those in the .Zip to a working directory.
To see the test wrapper in action ...
1) At the comand prompt, use "COMPILE TestCode /TESTING"
2) This creates TestCode.Lst and TestCode.Spin
3) Open PropTool, load TestCode.Spin
4) Edit _CLKMODE, _XINFREQ and TV_PIN
5) F10 download and enjoy
To see the single-stepper in action ...
1) Use "COMPILE TestCode /DEBUG"
2-5) As above
Use "COMPILE /?" for details on options. The /ALIGN's work up to the .Lst file but the Spin generator won't handle them properly. Other bugs ad missing functionality as well, but at least it proves it's working as far as it works.
It can now access the Special Purpose Registers (SPR) at $1F0..$1FF.
Q : Not being a C programmer myself; how would this normally be done in C ?
I made the decision to have my converter translate access to the standard named variables to SPR so this allows their simple use as in "OUTA = OUTA ^ ( 1 << 9 )" to toggle P9 etc. Because LCC has no idea of "OUTA" all those used to be explicitly defined; "int OUTA;" ( must be all uppercase ), the converter handles the rest.
There's no WaitCnt() but you can see it work by using "COMPILE FlashLed /DEBUG" which single-steps at a slow rate. Remove the WaitCnt() in the generated FlashLed.Spin file for fast flashing.
Next milestones ...
1) Kernel Libraries ( for Integer/Signed Multiply, Divide, Square Root )
2) System Libraries ( for WaitCnt() etc )
3) Floating Point Libraries
Help needed ...
Anyone with any experience of compiling LCC source ( from Princeton University or the Id Software Quake 3 version ) under Windows using a free of cost commercial use Win32 C compiler which doesn't involve the world's most complex configuration ( no mingw, cygwin etc ) ?
Anyone prepared to make that happen and produce a How To ?
Hippy, please do not add automatic access to "standard names." That's an unnecessary kludge! You would do something like
#define OUTA (*(volatile unsigned int *)0x???)
and you can use OUTA exactly as your example. The only trick is that in Propeller, there are two address space - Cog and Hub, with Cog being 32 bits addressable and Hub being byte addressable. You will have to decide how the compiler differentiate between the two spaces. For me, I punted: a constant address 0x1FF or lower is considered as a 32 bits Cog address. This means accessing to Hub RAM below 0x200 by address indirection as above is no longer trivial (but still very easy), but allow Cog space access transparently.
I'd personally take the GCC inspired route
long OUTA __attribute__(cog(addr));
While were on the subject, I'm working on a 16-bit-wide instruction VM on which to run a variety of languages. The instruction set is very like PASM, except code is executing out of the hub, you have 16 registers, instructions can't be condition coded (You have to use the skips, soz/soc/socz, or the jumps, jz/jnz/jc/jnc/jzc/jnzc/jznc/jnznc), and you have a mul.
This sounds quite standard, except there is one other thing to consider: the instructions LMM and FCACHE.
LMM aligns the PC on a long boundry and begins executing code from there,
FCACHE aligns the PC on a long boundry, loads the code into the buffer, then jumps there
The architecture also has another quirk: PC is one of the 16 registers. As such, JMP addr is actually just MOV pc, addr.
Thanks for that, and it solved a few other problems.
It's even worse in my case as there are three areas; cog, hub and LMM code/data area. Looking at the code generated it looks to have been possible to distinguish LMM ( &myVar ) references from SPR ( &DIRA) references, and to access the few important hub locations by name, the rest by value ...
Hippy,
You only need the "volatile" keyword on items that may be changed by hardware while the thread is running or for which writes cause side effects. For instance, a write to OUTA causes a side effect (outputting the value). INA can be changed by the hardware. PAR can't change (once the thread is running) and hence doesn't need to be volatile. This is probably a moot point as I doubt lcc will do the kinds of optimizations that "volatile" prohibits it from doing, but in case it does, I figured I'd toss that out....
Sadly, I can't help you on Windows compilation tools as I'm a Mac/Linux/Unix guy (the lack of a port to those OS's is why I haven't bought ImageCraft's compiler already.... See comment about "world's most complex configuration" and apply to Wine). I can, however, answer most questions about C [noparse]:)[/noparse]
When I'm auto-linking this to my internal system library, should I match on an exact "WaitCnt" case match or should I accept it regardless of case ? And if it has to be an exact match what should it be - "WaitCnt", "waitcnt" or "WAITCNT" - Spin allows any.
@ Forest : Thanks. Should have spotted that ! Not sure what LCC does.
Forest is right, but one thing was not made clear although it was implied. The volatile keyword forces the compiler to use the statement regardless of optimization. Thus if you require two hardware writes back to back to make your driver work and you have an optimizing compiler, the compiler won't just throw away what it may consider a redundant operation.
BTW: using WaitCnt as a function doesn't make much sense because of overhead. That's why WAITCNT and other inline asm("....") statements are macros in ICC. Some inline asm should be inline functions because of variable requirements and macros are a PITA to use, but that is not defined in that LCC standard. When inline functions are available the spelling of some macros will become lower case.
@ Jazzed : Thanks for that. In the absence of asm() we're stuck with it this way for now, and it makes the initial compiler easier to write.
It's slightly complicated under the hood as all my internal libraries expect their arguments to be at top of stack but in a call to function they aren't, so they need to be moved from the 'argument frame' to stack then the function called. The advantage is that function calling convention and library interface is consistent with just this minor hack as the middle-man. The disadvantage is slower execution, but I'm after compact code rather than speed, plus ease of writing the code !
Anyone with any experience of compiling LCC source ( from Princeton University or the Id Software Quake 3 version ) under Windows using a free of cost commercial use Win32 C compiler which doesn't involve the world's most complex configuration ( no mingw, cygwin etc ) ?
Anyone prepared to make that happen and produce a How To ?
Hippy, Cygwin is not that bad and is quite easy to install. I have MSVC++ 6.0 installed and was able to produce an lcc42 lcc.exe file like this:
1. unzip lcc42 package to c:\lcc42
2. set BUILDDIR=c:\lcc42\version\bin
3. edit etc\win32.c #define LCCDIR "c:\\lcc42\\version\\bin\\"
4. nmake -f makefile.nt HOSTFILE=etc\win32.c lcc
-- apparently many files are precomiled ....
5. ran version\bin\lcc.exe and got big help screen
Everything helps. I don't have MSVC++ or NMAKE but I'll see what I can achieve; it looks simple enough once compilation can be got going. I found a web page which suggested Visual c++ Express could work so may try that.
There's not a desperate need to compile LCC but using the Quake port throws a lot of assert failures and GPF's when the source is incorrect so expect people would like to be able to get that side of things fixed.
@ OwenS : That's not a problem - I use XP ( have to for the PropTool ) but do prefer Win98.
@ heater : "Bloodshed C++ ... No HOWTO required" - famous last words The Source Forge download link isn't delivering the file and the SimTel link downloads a download manager which does download it but clicking "RUN" in the download manager says I don't have a viewer and exits and I cannot find whatever it's downloaded on disk. Found an alternative download but that tells me I don't have GNU make when I run it. Too much pissing about for me at the moment.
Oh for the happy days of "CC MyFile.c and - voila - one MyFile.exe ready to run.
@Hippy. Cygwin would be so much easier to use at this point. You really should give it a try. After basic installation, you can choose software from a GUI package list. GNU gcc, etc... should come as part of the package. Once you have it installed you can run gcc or make in any new command window. Good luck. http://www.cygwin.com/setup.exe
I'm not sure where this thred is going, but I'd put in my 2centavos
I prefer MinGW as it doesn't require all the DLLs that Cygwin uses.· I've been burned by Cygwin based tools, from time to time, as I load some other one, it replaces a DLL or 2 and that breaks other Cygwin tools that had been running up til then.· This is due to version issues and differing interfaces to the DLLs
MinGW compiles to standalone .exe files which have pretty much worked everywhere. ·
@ plx88 : Thanks for that reminder. I've already got Borland 5.5 installed and that is a case of "BCC32 filename.c" and out comes an .exe so that's happy territory.
@ jazzed : Cygwin installed ( not that I have a clue what to do within it ), but there doesn't seem to be a gcc.
@ viskr : Thanks for the recommendation but as with Cygwin, I've no experience of MingW. It's also lacking the simplicity of setup.exe and working out the box.
It looks like Borland ( or something like it ) is the way to go for me. It compiles some of the .c files but I've yet to untangle the makefile and put it all back together as something which works.
I'd hoped it would be easy but apparently not. In the battle for priorities this has to take a back seat to the bytecode conversion so I'll put it to one side for now. If anyone wants to come up with a plug-n-play solution which installs and works please do so.
What do you need from the "Plug-n-play" solution ? I can build LCC, but I'm not sure what is needed or how to proceed.
To "check" for GNU and/or install, you need to run the Cygwin setup.exe. Before you run install,·from a new·DOS·command window, enter "ls c:\CygWin\bin | grep gcc" ... I get this:
If you can't use "ls" and "grep", something is wrong with your installation.
If you don't see gcc, run setup.exe, specify "Install from Local Directory" at the wizard dialog so you don't end up downloading a bunch of stuff. Follow the "Next" until you see the packages list (sample attached). If you don't have Devel -> gcc marked as "Keep", "cancel" setup, then run setup.exe again but use install from internet .... Once you get to the packages screen, you should check the items listed in the attachment.
That's a shame. I just reinstalled it again to remind myself what the problems were. There were none.
Just downloaded devcpp-4.9.9.2-setup.exe from sourceforge to my XP desktop, double click, click, click .. just like a normal windows installer and hello world was compiled and running in a couple of mins.
Happened to be from the University of Kent mirror:
@ heater : Found the Bloodshed files downloaded and they installed fine. Works okay. Doesn't support my default colour scheme though and inbuilt Preferences don't help, so I'm ending up with 'invisible' white-on-white source code
@ jazzed : My big mistake was not ticking the include gcc box. Now it's installed I'm happy to go with that.
LCC 4.2 Source in C:\LCC42
Cygwin prompt show -
Adminstrator@winxp
$
"ls -R c:/lcc42" shows all the LCC 4.2 files. "gcc" correctly tells me I haven't provided an input file or "x.c" doesn't exist so that seems to be setup and working.
The question is ... what next ? What's the magic command I need to get to the next stage ?
( Makes a change getting to wear a "newbie" badge )
RTFM? Look at <LCC path>\doc\install.html That's where I got the MSVC++6.0 build process. The "Unix Install" is not very straight up as current linux builds are these days. I'm not up to the task of describing how to do all this now since it's so late. You might consider the MSVC++ steps I posted earlier as kind of a guide ... don't bother with symbolic links since MrSoftie doesn't support them. I'll be fresher tomorrow and will have another look. C-ya.
Comments
; i -> R0
_main::
add R0,#1
Can't get any shorter than that
What it really shows is increment is a special case and frequent enough in real life to optimise specifically. A more realistic test might be how many additions of a certain value in a particular time. But then we're into all sorts of problems in fair comparisons because some values fare better than others and that varies from VM to VM.
If we wanted we could even add specific bytecode which performs a particular task to bump the ratings up. I'm sure that happens from good intent anyway as people see different things they would optimise. I think it only becomes unscrupulous when optimising in order to achieve a good benchmark score.
The other problem of benchmarking is comparing like with like, something meant for bit-twiddling is likely to perform worse at floating point than something meant for floating point and vice-versa.
It was interesting to read the comments on fast square rooting in a another thread. I don't think I've used square root that many times ( and never on a micro ) so for me that would go way down the priority list for fast execution, same with multiply, divide, mod and anything floating point.
Now, I have to close the circle and finish the assembler.
Second major milestone reached - One LCC VM which actually runs. You'll need Id Software's Quake 3 port of LCC ( instructions in ReadMe.Htm ). Install the three required files and all those in the .Zip to a working directory.
To see the test wrapper in action ...
1) At the comand prompt, use "COMPILE TestCode /TESTING"
2) This creates TestCode.Lst and TestCode.Spin
3) Open PropTool, load TestCode.Spin
4) Edit _CLKMODE, _XINFREQ and TV_PIN
5) F10 download and enjoy
To see the single-stepper in action ...
1) Use "COMPILE TestCode /DEBUG"
2-5) As above
Use "COMPILE /?" for details on options. The /ALIGN's work up to the .Lst file but the Spin generator won't handle them properly. Other bugs ad missing functionality as well, but at least it proves it's working as far as it works.
Maybe inspired by Carl's approach to JDForth ?
I added a couple of hotkeys to my Source Edit to handle the compiler options, for a bit of fun.
Keep up the good work
It can now access the Special Purpose Registers (SPR) at $1F0..$1FF.
Q : Not being a C programmer myself; how would this normally be done in C ?
I made the decision to have my converter translate access to the standard named variables to SPR so this allows their simple use as in "OUTA = OUTA ^ ( 1 << 9 )" to toggle P9 etc. Because LCC has no idea of "OUTA" all those used to be explicitly defined; "int OUTA;" ( must be all uppercase ), the converter handles the rest.
There's no WaitCnt() but you can see it work by using "COMPILE FlashLed /DEBUG" which single-steps at a slow rate. Remove the WaitCnt() in the generated FlashLed.Spin file for fast flashing.
Next milestones ...
1) Kernel Libraries ( for Integer/Signed Multiply, Divide, Square Root )
2) System Libraries ( for WaitCnt() etc )
3) Floating Point Libraries
Help needed ...
Anyone with any experience of compiling LCC source ( from Princeton University or the Id Software Quake 3 version ) under Windows using a free of cost commercial use Win32 C compiler which doesn't involve the world's most complex configuration ( no mingw, cygwin etc ) ?
Anyone prepared to make that happen and produce a How To ?
#define OUTA (*(volatile unsigned int *)0x???)
and you can use OUTA exactly as your example. The only trick is that in Propeller, there are two address space - Cog and Hub, with Cog being 32 bits addressable and Hub being byte addressable. You will have to decide how the compiler differentiate between the two spaces. For me, I punted: a constant address 0x1FF or lower is considered as a 32 bits Cog address. This means accessing to Hub RAM below 0x200 by address indirection as above is no longer trivial (but still very easy), but allow Cog space access transparently.
long OUTA __attribute__(cog(addr));
While were on the subject, I'm working on a 16-bit-wide instruction VM on which to run a variety of languages. The instruction set is very like PASM, except code is executing out of the hub, you have 16 registers, instructions can't be condition coded (You have to use the skips, soz/soc/socz, or the jumps, jz/jnz/jc/jnc/jzc/jnzc/jznc/jnznc), and you have a mul.
This sounds quite standard, except there is one other thing to consider: the instructions LMM and FCACHE.
LMM aligns the PC on a long boundry and begins executing code from there,
FCACHE aligns the PC on a long boundry, loads the code into the buffer, then jumps there
The architecture also has another quirk: PC is one of the 16 registers. As such, JMP addr is actually just MOV pc, addr.
Post Edited (OwenS) : 9/2/2008 9:31:30 PM GMT
It's even worse in my case as there are three areas; cog, hub and LMM code/data area. Looking at the code generated it looks to have been possible to distinguish LMM ( &myVar ) references from SPR ( &DIRA) references, and to access the few important hub locations by name, the rest by value ...
You only need the "volatile" keyword on items that may be changed by hardware while the thread is running or for which writes cause side effects. For instance, a write to OUTA causes a side effect (outputting the value). INA can be changed by the hardware. PAR can't change (once the thread is running) and hence doesn't need to be volatile. This is probably a moot point as I doubt lcc will do the kinds of optimizations that "volatile" prohibits it from doing, but in case it does, I figured I'd toss that out....
Sadly, I can't help you on Windows compilation tools as I'm a Mac/Linux/Unix guy (the lack of a port to those OS's is why I haven't bought ImageCraft's compiler already.... See comment about "world's most complex configuration" and apply to Wine). I can, however, answer most questions about C [noparse]:)[/noparse]
-- Forest
And another question for a C programmer ...
extern void WaitCnt( unsigned int cntMatch ); void main() { while (1) { WaitCnt( CLKFREQ / 1000 * 10 + CNT ); // Wait 10ms } }When I'm auto-linking this to my internal system library, should I match on an exact "WaitCnt" case match or should I accept it regardless of case ? And if it has to be an exact match what should it be - "WaitCnt", "waitcnt" or "WAITCNT" - Spin allows any.
@ Forest : Thanks. Should have spotted that ! Not sure what LCC does.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
BTW: using WaitCnt as a function doesn't make much sense because of overhead. That's why WAITCNT and other inline asm("....") statements are macros in ICC. Some inline asm should be inline functions because of variable requirements and macros are a PITA to use, but that is not defined in that LCC standard. When inline functions are available the spelling of some macros will become lower case.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
It's slightly complicated under the hood as all my internal libraries expect their arguments to be at top of stack but in a call to function they aren't, so they need to be moved from the 'argument frame' to stack then the function called. The advantage is that function calling convention and library interface is consistent with just this minor hack as the middle-man. The disadvantage is slower execution, but I'm after compact code rather than speed, plus ease of writing the code !
1. unzip lcc42 package to c:\lcc42
2. set BUILDDIR=c:\lcc42\version\bin
3. edit etc\win32.c #define LCCDIR "c:\\lcc42\\version\\bin\\"
4. nmake -f makefile.nt HOSTFILE=etc\win32.c lcc
-- apparently many files are precomiled ....
5. ran version\bin\lcc.exe and got big help screen
Hope this doesn't come too late to be useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
There's not a desperate need to compile LCC but using the Quake port throws a lot of assert failures and GPF's when the source is incorrect so expect people would like to be able to get that side of things fixed.
www.bloodshed.net/devcpp.html
I tried it out a while back and seem to remember it installed very easily and just worked. At least on my XP laptop. No HOWTO required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@ heater : "Bloodshed C++ ... No HOWTO required" - famous last words
Oh for the happy days of "CC MyFile.c and - voila - one MyFile.exe ready to run.
Supplementary Information regarding Borland C++ 5.5 Command-line Tools
Using the Borland 5.5 Compiler and command-line tools
http://www.cygwin.com/setup.exe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I prefer MinGW as it doesn't require all the DLLs that Cygwin uses.· I've been burned by Cygwin based tools, from time to time, as I load some other one, it replaces a DLL or 2 and that breaks other Cygwin tools that had been running up til then.· This is due to version issues and differing interfaces to the DLLs
MinGW compiles to standalone .exe files which have pretty much worked everywhere.
·
@ jazzed : Cygwin installed ( not that I have a clue what to do within it ), but there doesn't seem to be a gcc.
@ viskr : Thanks for the recommendation but as with Cygwin, I've no experience of MingW. It's also lacking the simplicity of setup.exe and working out the box.
It looks like Borland ( or something like it ) is the way to go for me. It compiles some of the .c files but I've yet to untangle the makefile and put it all back together as something which works.
I'd hoped it would be easy but apparently not. In the battle for priorities this has to take a back seat to the bytecode conversion so I'll put it to one side for now. If anyone wants to come up with a plug-n-play solution which installs and works please do so.
To "check" for GNU and/or install, you need to run the Cygwin setup.exe. Before you run install,·from a new·DOS·command window, enter "ls c:\CygWin\bin | grep gcc" ... I get this:
If you can't use "ls" and "grep", something is wrong with your installation.
If you don't see gcc, run setup.exe, specify "Install from Local Directory" at the wizard dialog so you don't end up downloading a bunch of stuff. Follow the "Next" until you see the packages list (sample attached). If you don't have Devel -> gcc marked as "Keep", "cancel" setup, then run setup.exe again but use install from internet .... Once you get to the packages screen, you should check the items listed in the attachment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Just downloaded devcpp-4.9.9.2-setup.exe from sourceforge to my XP desktop, double click, click, click .. just like a normal windows installer and hello world was compiled and running in a couple of mins.
Happened to be from the University of Kent mirror:
sourceforge.net/project/downloading.php?groupname=dev-cpp&filename=devcpp-4.9.9.2_setup.exe&use_mirror=kent
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
From my DOS box:
C:\>Dev-Cpp\bin\gcc.exe -o hello hello.c
C:\>hello
Hello
C:\>
I must have got lucky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
http://www.openwatcom.org/
@ jazzed : My big mistake was not ticking the include gcc box. Now it's installed I'm happy to go with that.
LCC 4.2 Source in C:\LCC42
Cygwin prompt show -
Adminstrator@winxp
$
"ls -R c:/lcc42" shows all the LCC 4.2 files. "gcc" correctly tells me I haven't provided an input file or "x.c" doesn't exist so that seems to be setup and working.
The question is ... what next ? What's the magic command I need to get to the next stage ?
( Makes a change getting to wear a "newbie" badge )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve