I'd studied the install.htm and even worked out to replace 'setenv' with 'set', swap \ for / and have searched Google for how to compile under cygwin ( no joy ). The trouble is I'm in completely unfamiliar territory with a never before used tool chain (cygwin/gcc), a build process for tools I don't have and never got to work and no idea how to convert that. I'm not sure which or if there is a manual to RTF. I'm stuck at the same point with Windows and Borland 5.5 and Cygwin and gcc; making the 'make' process make.
I'm sure I could get either working with enough time ( or an infinite number of monkeys ) but to do that now would delay work on the LCC to Propeller conversion which I believe has to be the priority so I'm looking for one bright and experienced 'monkey' to help with the building LCC side of things, deliver that 'plug-and-play' solution.
Your help is greatly appreciated and I know I'm perhaps asking for a lot. It's not a desperate priority at the present time but anything you can help with at your leisure will be appreciated. I'm perhaps just missing something simple because my mind's focused somewhere else, knee deep in stack frames and pointers as well as other parts of real life. Juggling LCC building as well is just one ball too many.
hippy, as soon as I'm at home I'll send you my makefile for lcc together with my progress (in a couple of hours). I normally use cygwin from the cygwin command line so it is a bash shell.
Edit: you have to create the build directory inside the lcc one and just run make. flex or lex, yacc or bison are needed but you probably already have those. Change the target to winblows instead of linux. The included executables are for x86-64 on Ubuntu 8.04.
Hippy, you're not asking for much. I used this proceedure to build lcc.exe:
Open the cygwin command shell using C:\CygWin\cygwin.bat or use cute little shortcut in "start".
cd /cygdrive/c/lcc42··/* c is lower case version of your disk partition */
export BUILDDIR="/cygdrive/c/lcc42/custom/bin"
mkdir $BUILDDIR
mkdir /cygdrive/c/lcc43/custom/include
ln -s /usr/lib/gcc-lib/i686-pc-mingw32/3.3.3· $BUILDDIR/gcc··/* 3.3.3 is my version ... use your version */
ls $BUILDDIR· /* output should show·bin, gcc, and include */
Save·the attached file to·/cygdrive/c/lcc42/etc/cygwin.c or C:\lcc42\etc\cygwin.c /* this might need modifications later */
In cygwin command shell /cygdrive/c/lcc42 enter:· make HOSTFILE=etc/cygwin.c lcc
To do "make all" for building rcc.exe, you will need to get the Devel -> byacc package. After you get the package, cd /bin in cygwin shell. Then use ln -s byacc.exe yacc.exe to create a link to yacc for make all to use.
I ran "make all", but I think it failed at the point where lcc is looking for an instruction set. I may look into this more later today. BTW: use "make clean" before trying "make all" again if you want to start fresh.
The etc/cygwin.c file may not be perfect for all applications.
Added: Ale, I didn't see your response before trying this ... just as well. I expect you've gotten further than me.
Thanks. That makes sense. Not sure if "include" should be "...custom/include" or "...custom/bin/include" but those are things I can work round getting right ( I created both as a stopgap ).
The problem I'm now hitting is with make -
Administrator@winxp /cygdrive/c/lcc42
$ ls $BUILDDIR
bin gcc include
Administrator@winxp /cygdrive/c/lcc42
$ make HOSTFILE=etc/cygwin.c lcc
15708 [noparse][[/noparse]main] bash 1472! _pinfo::dup_proc_pipe: DuplicateHandle failed, pid 147
2, hProcess 0x6FD, wr_proc_pipe 0x754, Win32 error 6
Microsoft (R) Program Maintenance Utility Version 4.07
Copyright (C) Microsoft Corp 1984-1988. All rights reserved.
MAKE : fatal error U1008: lcc : cannot find file
Back to core development and more milestones reached -
* System libraries working ( signed/integer multiply, divide, modulus )
* Support for WaitCnt() etc
* Floating Point ( not all functions yet )
So that's really DIY C for Propeller "done".
There are still a few annoying bugs to track down and fix and then there's a need to rewrite the utility programs which do the work to clean them up and make them more logical and maintainable. Plus finishing the library code and tidying up the kernel source.
Not sure I understand the question. I'm using -target=bytecode so the Quake 3 port is okay for now. A self-compiled LCC should hopefully be just the same but not Quake-branded.
Question reshaped: What needs to be done to finish "DIY Propeller C" ? Do you have a windows or other OS executable that I can use to compile a C program that produces a binary image which will run on your VM ?
I've re-jigged the entire tool chain so it's easier for me and to use. A few annoying buggettes overcome, like LCC not working properly if it's not in the PATH, and support for linking multiple .c files added.
Of course it's failed regression testing Not it looks in a major way but it will take some extra effort to get it back into shape for release. A couple of days. That won't be a perfect but will work. To use it will be a case of "Compile file{.c} {/options}" then load the resulting file.spin into the Prop Tool, F10 and watch.
@hippy: Let me get this straight; in 15 days you've managed to build a C compiler that takes a C file and converts it to a form that can be downloaded & run on the Propeller?!
I bow before you. No, seriously, I am in utter awe
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again BTW: I type as I'm thinking, so please don't take any offence at my writing style
It's been a hard slog and I've completely blown my body-clock. Not sure which nations' timezone I'm in synch with now.
TBH the hard part was already done with LCC ( the actual compiler ) already written and Id Software providing an executable which churns out bytecode. Nonetheless it wasn't as straight forward as I'd hoped. One needs to understand what the virtual machine is to clone it in a reality and I still haven't got my head round the way it does its stack framing. I've got my own variant which holds up in testing and observing the code generated - if needs be I can come back and revisit that.
The rest has really been in writing the tools, the PASM kernel, ironing out the bugs and testing. The bugs I introduced seem to have been eradicated so it's definitely the home stretch, probably easier to say what doesn't work than does. There are a few notable absences ( bugs for structures and library calls ) but it's hopefully now just the hard grind of ticking them off one at a time. I need to take a break, catalogue what doesn't work and prioritise fixes. Once I've check the basic integer stuff is working I'll make a release.
I'm not as convinced code density will be as high ( or as fast ) as I'd hoped; LCC does some peculiar things - a sort of stack-register/true-stack combo - which I guess is down to the peculiarities of C ( x = y++ etc ). I had to take some of my evaluation optimisation out but execution path optimisations are working okay.
Given that I've only written a back-end and that's not complete yet I'm not sure if it's awe inspiring or not.
Finally ( though I suppose it is just three weeks - It feels like I've put a lot more work into it than that, I'm shattered ! ), something worthy of a 1.00 release.
I wouldn't put any faith in anything floating point but addition and multiply seem to work.
There's still work to be done but it does compile and run C code. Assuming Fibo(29) worked correctly it ran in about 35 seconds. Slower than Spin but not too bad and it was code density rather than speed I was after. TBH it wasn't even that, just to see if I could, if it would even work, and to see if a stack machine holds its own against a register architecture
It's going to be interesting to see what effect caching the top of stack has.
COMPILE /? -- is the only help you're getting but hopefully it's enough for now along with the examples
COMPILE filename{.c} /TEST -- shows on the TV what the variables hold
COMPILE filename{.c} /DEBUG -- shows the executing bytecode
You can use multiple C files in a project and it's clever enough not to include them twice so this will work ...
COMPILE MyProg.c *.c /TEST/PROTOBOARD
Add /LOG ( and-or /VERBOSE ) and you'll get to see what's happening in more detail.
Even though I'm not a C programmer I know I've missed things out like being able to pass #define constants into the compiler and set #include paths. They'll perhaps get added with the fullness of time.
At least the first report wasn't "It don't work". The "U" has alternate bits set but I guess it gives a nice welcome
As to multiple C objects. Each complete C program can be included as a separate object and will run in its own cog with its own memory for stack, much like CogNew for Spin methods ...
OBJ
x : "x.Lcc"
y : "y.Lcc"
VAR
long xStack[noparse][[/noparse]1000]
long yStack[noparse][[/noparse]500]
PUB Main
x.SetStack(@xStack,1000)
y.SetStack(@yStack,500)
x.Main
y.Main
Inter-C program comms is down to the C program. It's possible to pass parameters into Main or other functions ( see the Exported Methods section after COMPILE x /OBJECT ) so they can be told where shared memory is if the want it. I've got some of the names wrong and the exports aren't complete - Added to the To Do list.
I meant multiple C objects in a different way although your interpretation of my question is intriguing.
Consider the following: Most C applications are divided into several parts depending on the user. It might look like this:
main.c - has application enty point "int main(int argc, char** argv)"
crt0.s - has startup required to run main.
libc.a - the standard C library API module
serial.c - a serial device driver API module
etc....
Except for libc.a (which contains .o files) all the implementation files will be used to generate .o "object files" in COFF, ELF, or other formats. These are the C objects to which I referred. A tool-chain usually has a linker and archiver in addition to compiler and assembler. To do serious work leveraging any pre-existing code such as what is in the OBEX, the tool-chain is necessary.
Regardless of tool-chain, I think what you have produced offers a fresh view of C, and I look forward to more exploration of it as time permits.
@ jazzed : Aha, those sort of objects. Compile with the /NOTIDY switch and there are *.$bo files which are the equivalents of the .o files but in text form.
There's no separate linker at present, this is part of Compiler.Exe, so to create an application which used TvText.c and Printf.c say it would be "COMPILE MyApp TvText Printf" or MyApp.c could #include <TvText.c> etc. crt0.s and libc.a are currently hard-wired into Kernel.Spin.
I'm not a C programmer but this means of building applications seems to work well enough for other languages which don't get access to .o and other pre-compiled object files. I guess it depends on what one's used to. I'll have a go at building an app using stuff from OBEX.
@ Ron : Thanks for being brave enough to try it.
1) No newline ... That's down to LCC itself which is out of my hands at the moment.
2) I seem to have lost the actual code which does RxByte, not just in the generated file but in the Kernel. I'll fix that.
@hippy
I will go throught some of my ADC and GPS parser C#· stuff tomorrow and mod them so that I can give them a run through·your··"Blender"· [noparse]:)[/noparse]
Yes, I noticed many lib routines in the spin code ... very handy. Being able to "compile and link" many files is key however it's done. Thanks for the pointer about multiple files ... it didn't occur to me to try that because I usually use a makefile that compiles one .c file at a time.
Yes, I noticed many lib routines in the spin code ... very handy. Being able to "compile and link" many files is key however it's done. Thanks for the pointer about multiple files ... it didn't occur to me to try that because I usually use a makefile that compiles one .c file at a time.
What is the @filename.cmd option ?
I've never used makefiles ( that probably showed in my problems trying to get LCC to compile ), so it comes down to what environment one is used to.
@filename.cmd allows the command line to be put into a file rather than on the command line itself. This gets round annoying issues with MS-DOS / Windows refusing to pass long command lines from IDE's. It also gives a convenient sort of 'macro' use if compiling frequently, so you can have "debug.cmd" and "test.cmd" files etc. The filename.cmd can be multi-line so these are equivalent -
@ Ron : Attached patch which gives you RxByte. Note it's not buffered so if it's called too infrequently it will drop / corrupt characters. It doesn't validate stop bit so there's 1.5 bit time worth of processing available for back-to-back received data ( 312uS at 4800 baud, 156uS at 9600 ). Tested to 115200 baud.
@hippy: I've compiled the latest SVN version of LCC using MinGW 4.2.1. This zip has the resultant cpp.exe and rcc.exe, both renamed with a q3 in front. Let me know if they work for you?
edit: Oh, sorry, forgot to say, "great job!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
@ lonesock : You're a hero. Runs under Windows 98 too. No .DLL's required so that's one up on Cygwin and it's been no-go under Windows without MSVC.
Cpp.Exe was perfect, Rcc.Exe had one major divergence from Id's Q3rcc and one minor, both of which affect what I'm doing but should be fixable with simple edits of the .\src\bytecode.c file ...
case CALL:
assert(p->kids[noparse][[/noparse] 0 ]);
assert(!p->kids[noparse][[/noparse] 1 ]);
assert(optype(p->op) != B);
dumptree(p->kids[noparse][[/noparse] 0 ]);
print("%s\n", opname(p->op));
[b]if ( !p->count ) { printf("pop\n"); };[/b] // Add this
return;
Interface bytecodeIR = {
1, 1, 0, /* char */
2, 2, 0, /* short */
4, 4, 0, /* int */
4, 4, 0, /* long */
4, 4, 0, /* long long */
4, 4, 1, /* float */
[b]4, 4, 1, /* double */[/b] // Change from 8, 8, 1
[b]4, 4, 1, /* long double */[/b] // Change from 8, 8, 1
4, 4, 0, /* T* */
The first ( "pop" ) sorts out dropping a return value when a function is called without an assignment, the second keeps doubles as 32-bit. All other slight differences my toolchain shrugged off or dealt with.
What would be really useful for me would be for the bytecode file to contain an "errors x y" line where x and y are the number of errors and warnings given. I don't care where it goes in the file or in what actual format.
So if you fancy a bit of compiler hacking to add to your CV
If you want to replicate bytecode.c as propcode.c and support -target=propcode you're welcome to.
No need to rename to a Q3 prefix ( in fact it's better if you don't ); leave them as whatever's generated or change them to PropCpp / PropRcc or claim some fame as lonesockCpp / lonesockRcc. My tools will look for that then fall back to Q3 stuff in their absence so nothing will get broken.
This I believe sorts out licensing issues for distributing Lcc executables so many thanks for doing this.
@hippy: OK, here is the new version with the updated bytecode.c. The Rcc and Cpp executables are renamed with a "prop" prefix. I did not include an error-/warning-count yet. I do see an error counter already in the code, but I do not see that for warnings, so I'll hold off for a bit. I also compiled this version optimized instead of with debug info, then used UPX to shrink the final exe's. If this version works, I'll delete the old zip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
It fixes the 64-bit double problem but seems to introduce a problem with how floats are represented. I suspect the source I have for Id's Q3rcc may not match the executable or I've mis-read something and it's going to need some more experimenting with. For now though the latest is good enough and you can delete the earlier .zip file. UPX works fine and I'd already compressed the Quake .exe's that way.
Using the test code, x.c ...
float f = 1.1;
void main() { }
And executing ...
[i]xxxx[/i]Rcc -target=bytecode x.c
Looking at the output, there's a constant halfway through ( "byte 4 <num>" ) ...
For Q3rcc Quake version : 1066192077
For Q3rcc first lonesock version : 1066192077
For PropRcc : 4309196
@Hippy
I have posted the test file zip.
I would be interested to know how you would deal with linking the spin file
I am unclear on the correct syntax for NEWCOG for the keyin method.·
Having witten the test code it occurred to me that if a modified tv_text.spin file was the Top object.
and pub main was added to Tv_text· like so.··
Pub Main()
TV.start(pinbase)······················· // Start Tv
adr := @screen ···· // get base adr of screen, then this would be nice
Myc#prog.start( adr, color)······ // Pass screen base address and color to Myc#Prog.c
Then in Myc#prog.c·················· //· at runtime if it were possible to >
color = PopStack······················ // Pop being a method by which the data from the top·
screen·= PopStack··················· // object is recovered
Carl’s JDFoth uses such a scheme to pass args between forth and spin via the word spin (in out).· Spin(2,0)· must be the last line in the Forth object following BYE.· After compile, the generated bytecode will expect to pop two longs off the stack LIFO fashion at runtime, it’s a dream to use.
Likewise Spin (0, 2) forth would push two longs onto the stack for the spin object on its return. BTW the correct syntax is 2 0 SPIN· or· 0 2 SPIN.
I downloaded your patch, thanks.
I want to·test my ADC and GPS C# stuff but can’t see the easy way
To link your generated bytecode to other spin objects.
Just some thoughts.
I modified Steve's TV_text.c·some time ago to use with my Tiny WP··I will·look at·that again, looks like I can compile multiple files.
Jazzed has probably already done it.
Regards
Ron
Post Edited (Ron Sutcliffe) : 9/13/2008 2:17:09 PM GMT
Comments
I'm sure I could get either working with enough time ( or an infinite number of monkeys ) but to do that now would delay work on the LCC to Propeller conversion which I believe has to be the priority so I'm looking for one bright and experienced 'monkey' to help with the building LCC side of things, deliver that 'plug-and-play' solution.
Your help is greatly appreciated and I know I'm perhaps asking for a lot. It's not a desperate priority at the present time but anything you can help with at your leisure will be appreciated. I'm perhaps just missing something simple because my mind's focused somewhere else, knee deep in stack frames and pointers as well as other parts of real life. Juggling LCC building as well is just one ball too many.
Edit: you have to create the build directory inside the lcc one and just run make. flex or lex, yacc or bison are needed but you probably already have those. Change the target to winblows instead of linux. The included executables are for x86-64 on Ubuntu 8.04.
Have fun. It is a tar bzipped2 file
Post Edited (Ale) : 9/5/2008 6:05:47 PM GMT
To do "make all" for building rcc.exe, you will need to get the Devel -> byacc package. After you get the package, cd /bin in cygwin shell. Then use ln -s byacc.exe yacc.exe to create a link to yacc for make all to use.
I ran "make all", but I think it failed at the point where lcc is looking for an instruction set. I may look into this more later today. BTW: use "make clean" before trying "make all" again if you want to start fresh.
The etc/cygwin.c file may not be perfect for all applications.
Added: Ale, I didn't see your response before trying this ... just as well. I expect you've gotten further than me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
The problem I'm now hitting is with make -
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
"make all", coughed, spluttered, fell over and kicked its legs in the air over dagcheck.* which is I guess where you got to.
At least we're heading down the right track. The help really has been appreciated.
* System libraries working ( signed/integer multiply, divide, modulus )
* Support for WaitCnt() etc
* Floating Point ( not all functions yet )
So that's really DIY C for Propeller "done".
There are still a few annoying bugs to track down and fix and then there's a need to rewrite the utility programs which do the work to clean them up and make them more logical and maintainable. Plus finishing the library code and tidying up the kernel source.
Once that's done I'll make a new release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I've re-jigged the entire tool chain so it's easier for me and to use. A few annoying buggettes overcome, like LCC not working properly if it's not in the PATH, and support for linking multiple .c files added.
Of course it's failed regression testing
I bow before you. No, seriously, I am in utter awe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
TBH the hard part was already done with LCC ( the actual compiler ) already written and Id Software providing an executable which churns out bytecode. Nonetheless it wasn't as straight forward as I'd hoped. One needs to understand what the virtual machine is to clone it in a reality and I still haven't got my head round the way it does its stack framing. I've got my own variant which holds up in testing and observing the code generated - if needs be I can come back and revisit that.
The rest has really been in writing the tools, the PASM kernel, ironing out the bugs and testing. The bugs I introduced seem to have been eradicated so it's definitely the home stretch, probably easier to say what doesn't work than does. There are a few notable absences ( bugs for structures and library calls ) but it's hopefully now just the hard grind of ticking them off one at a time. I need to take a break, catalogue what doesn't work and prioritise fixes. Once I've check the basic integer stuff is working I'll make a release.
I'm not as convinced code density will be as high ( or as fast ) as I'd hoped; LCC does some peculiar things - a sort of stack-register/true-stack combo - which I guess is down to the peculiarities of C ( x = y++ etc ). I had to take some of my evaluation optimisation out but execution path optimisations are working okay.
Given that I've only written a back-end and that's not complete yet I'm not sure if it's awe inspiring or not.
I wouldn't put any faith in anything floating point but addition and multiply seem to work.
There's still work to be done but it does compile and run C code. Assuming Fibo(29) worked correctly it ran in about 35 seconds. Slower than Spin but not too bad and it was code density rather than speed I was after. TBH it wasn't even that, just to see if I could, if it would even work, and to see if a stack machine holds its own against a register architecture
It's going to be interesting to see what effect caching the top of stack has.
COMPILE /? -- is the only help you're getting but hopefully it's enough for now along with the examples
COMPILE filename{.c} /TEST -- shows on the TV what the variables hold
COMPILE filename{.c} /DEBUG -- shows the executing bytecode
You can use multiple C files in a project and it's clever enough not to include them twice so this will work ...
COMPILE MyProg.c *.c /TEST/PROTOBOARD
Add /LOG ( and-or /VERBOSE ) and you'll get to see what's happening in more detail.
Even though I'm not a C programmer I know I've missed things out like being able to pass #define constants into the compiler and set #include paths. They'll perhaps get added with the fullness of time.
I'll pile some things together to test more later. Have you given any thought to linking multiple "C object" files into one spin-app ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
As to multiple C objects. Each complete C program can be included as a separate object and will run in its own cog with its own memory for stack, much like CogNew for Spin methods ...
Inter-C program comms is down to the C program. It's possible to pass parameters into Main or other functions ( see the Exported Methods section after COMPILE x /OBJECT ) so they can be told where shared memory is if the want it. I've got some of the names wrong and the exports aren't complete - Added to the To Do list.
Consider the following: Most C applications are divided into several parts depending on the user. It might look like this:
Except for libc.a (which contains .o files) all the implementation files will be used to generate .o "object files" in COFF, ELF, or other formats. These are the C objects to which I referred. A tool-chain usually has a linker and archiver in addition to compiler and assembler. To do serious work leveraging any pre-existing code such as what is in the OBEX, the tool-chain is necessary.
Regardless of tool-chain, I think what you have produced offers a fresh view of C, and I look forward to more exploration of it as time permits.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
void main() { while (1) { cx = RxByte(31,4800) ; TxByte( 30,4800, cx); } }[/code][/size]
@ Hippy, just FYI
1··Note the compiler warning . "No newline at EOF" ????· so what !
2· Compiles Ok, but·will not·run·in terminal.·(output is garbage in Hyperterm)
Regards
Ron
BTW· I am not sure that it will get much use at this end, but another great contribution from AiChip to the Prop Community.
Post Edited (Ron Sutcliffe) : 9/12/2008 2:40:26 PM GMT
There's no separate linker at present, this is part of Compiler.Exe, so to create an application which used TvText.c and Printf.c say it would be "COMPILE MyApp TvText Printf" or MyApp.c could #include <TvText.c> etc. crt0.s and libc.a are currently hard-wired into Kernel.Spin.
I'm not a C programmer but this means of building applications seems to work well enough for other languages which don't get access to .o and other pre-compiled object files. I guess it depends on what one's used to. I'll have a go at building an app using stuff from OBEX.
@ Ron : Thanks for being brave enough to try it.
1) No newline ... That's down to LCC itself which is out of my hands at the moment.
2) I seem to have lost the actual code which does RxByte, not just in the generated file but in the Kernel. I'll fix that.
The C standard requires files end with a newline. GCC is the same
@hippy
I will go throught some of my ADC and GPS parser C#· stuff tomorrow and mod them so that I can give them a run through·your··"Blender"· [noparse]:)[/noparse]
See what I come up with.
Ron
·
Yes, I noticed many lib routines in the spin code ... very handy. Being able to "compile and link" many files is key however it's done. Thanks for the pointer about multiple files ... it didn't occur to me to try that because I usually use a makefile that compiles one .c file at a time.
What is the @filename.cmd option ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
@filename.cmd allows the command line to be put into a file rather than on the command line itself. This gets round annoying issues with MS-DOS / Windows refusing to pass long command lines from IDE's. It also gives a convenient sort of 'macro' use if compiling frequently, so you can have "debug.cmd" and "test.cmd" files etc. The filename.cmd can be multi-line so these are equivalent -
Post Edited (hippy) : 9/12/2008 4:58:03 PM GMT
@ mpark : It's nothing compared to homespun !
edit: Oh, sorry, forgot to say, "great job!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Cpp.Exe was perfect, Rcc.Exe had one major divergence from Id's Q3rcc and one minor, both of which affect what I'm doing but should be fixable with simple edits of the .\src\bytecode.c file ...
case CALL: assert(p->kids[noparse][[/noparse] 0 ]); assert(!p->kids[noparse][[/noparse] 1 ]); assert(optype(p->op) != B); dumptree(p->kids[noparse][[/noparse] 0 ]); print("%s\n", opname(p->op)); [b]if ( !p->count ) { printf("pop\n"); };[/b] // Add this return; Interface bytecodeIR = { 1, 1, 0, /* char */ 2, 2, 0, /* short */ 4, 4, 0, /* int */ 4, 4, 0, /* long */ 4, 4, 0, /* long long */ 4, 4, 1, /* float */ [b]4, 4, 1, /* double */[/b] // Change from 8, 8, 1 [b]4, 4, 1, /* long double */[/b] // Change from 8, 8, 1 4, 4, 0, /* T* */The first ( "pop" ) sorts out dropping a return value when a function is called without an assignment, the second keeps doubles as 32-bit. All other slight differences my toolchain shrugged off or dealt with.
What would be really useful for me would be for the bytecode file to contain an "errors x y" line where x and y are the number of errors and warnings given. I don't care where it goes in the file or in what actual format.
So if you fancy a bit of compiler hacking to add to your CV
If you want to replicate bytecode.c as propcode.c and support -target=propcode you're welcome to.
No need to rename to a Q3 prefix ( in fact it's better if you don't ); leave them as whatever's generated or change them to PropCpp / PropRcc or claim some fame as lonesockCpp / lonesockRcc. My tools will look for that then fall back to Q3 stuff in their absence so nothing will get broken.
This I believe sorts out licensing issues for distributing Lcc executables so many thanks for doing this.
Post Edited (hippy) : 9/12/2008 8:22:40 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
It fixes the 64-bit double problem but seems to introduce a problem with how floats are represented. I suspect the source I have for Id's Q3rcc may not match the executable or I've mis-read something and it's going to need some more experimenting with. For now though the latest is good enough and you can delete the earlier .zip file. UPX works fine and I'd already compressed the Quake .exe's that way.
Using the test code, x.c ...
float f = 1.1; void main() { }And executing ...
Looking at the output, there's a constant halfway through ( "byte 4 <num>" ) ...
For Q3rcc Quake version : 1066192077
For Q3rcc first lonesock version : 1066192077
For PropRcc : 4309196
@hippy
@Hippy
I have posted the test file zip.
I would be interested to know how you would deal with linking the spin file
I am unclear on the correct syntax for NEWCOG for the keyin method.·
Having witten the test code it occurred to me that if a modified tv_text.spin file was the Top object.
and pub main was added to Tv_text· like so.··
Pub Main()
TV.start(pinbase)······················· // Start Tv
adr := @screen ···· // get base adr of screen, then this would be nice
Myc#prog.start( adr, color)······ // Pass screen base address and color to Myc#Prog.c
Then in Myc#prog.c··········· ······· //· at runtime if it were possible to >
color = PopStack······················ // Pop being a method by which the data from the top·
screen·= PopStack··················· // object is recovered
Carl’s JDFoth uses such a scheme to pass args between forth and spin via the word spin (in out).· Spin(2,0)· must be the last line in the Forth object following BYE.· After compile, the generated bytecode will expect to pop two longs off the stack LIFO fashion at runtime, it’s a dream to use.
Likewise Spin (0, 2) forth would push two longs onto the stack for the spin object on its return. BTW the correct syntax is 2 0 SPIN· or· 0 2 SPIN.
I downloaded your patch, thanks.
I want to·test my ADC and GPS C# stuff but can’t see the easy way
To link your generated bytecode to other spin objects.
Just some thoughts.
I modified Steve's TV_text.c·some time ago to use with my Tiny WP··I will·look at·that again, looks like I can compile multiple files.
Jazzed has probably already done it.
Regards
Ron
Post Edited (Ron Sutcliffe) : 9/13/2008 2:17:09 PM GMT