#12952 - 07/15/03 05:11 AM
Re: Who's using the Ocelot Compiler
|
Neil Cherry
junior
Registered: 01/17/03
Posts: 37
|
 It's summer time, be patient (at least in the northern hemisphere).
I setup my friend with the Ocelot (he and his wife love it) and I gave him the Ocelot compiler. He does not like the CMAX program (it's awkard) but he loves the compiler. I haven't needed to recompile yet but I have it for Linux & Windows (my friend is currently under Windows but a Linux box is in the works).
|
|
Top
|
|
|
|
|
#12953 - 07/15/03 07:35 AM
Re: Who's using the Ocelot Compiler
|
Brian Raynor
addict
Registered: 01/09/03
Posts: 454
Loc: Columbia, SC
|
Neil,
I hope to have an alpha of the decompiler (OCLD) that adds System Map support posted by the end of next week, if not earlier (depending on my work schedule).
There are a few changes I hope to incorporate into the compiler (OCLC) possibly before I post that, including correctly keeping original comments in the output, and possibly a few other things, depending on how hard that turns out to be.
One thing I am thinking of adding, which is a bit off in the future, is the ability to define label names in CMAX comments and have OCLD use them as its defined labels. This should be fairly straight forward and get around the fact that CMAX doesn't let you name labels. So long as you use OCLC/OCLD to edit your programs, the labels should go along with it, and still be viewable (via comments) in CMAX (and you could really change them in CMAX too if you like, as long as you are careful).
Any features that you, or anyone else, can think of, please let me know (no promises though) and I'll look into them. Also if you see any bugs (even in the current one), let me know, I'm trying to quash all that I find.
|
|
Top
|
|
|
|
|
#12955 - 07/16/03 05:21 AM
Re: Who's using the Ocelot Compiler
|
Brian Raynor
addict
Registered: 01/09/03
Posts: 454
Loc: Columbia, SC
|
Hi Drew. You can go to http://sourceforge.net/projects/oclc to get the old build of the Ocelot compiler along with some (incomplete) docs. This is before any of my changes went in. I have checked in a few changes, but not built the package yet so you can download it in one big swoop.
I hope to get around to updating the document in the next few weeks. That being said, it is sort of self-documenting as you can use the decompiler, OCLD, to take an existing Ocelot/Leopard program and convert it into OCLC source.
I did get your message now that I think about it. That was during a busy day and I did not get a chance to respond. Will respond to you now. :-)
I'll try to post some examples here next week along with the docs.
|
|
Top
|
|
|
|
|
#12956 - 07/18/03 08:13 PM
Re: Who's using the Ocelot Compiler
|
Neil Cherry
junior
Registered: 01/17/03
Posts: 37
|
Brian,
Definitely interested in the decompiler for both Windows Unix. I may not get to play with it right away as I'm in the process of moving 4 machines into 2 and I have a lot of software to migrate and upgrade!
Thanks for all the work.
|
|
Top
|
|
|
|
|
#12957 - 07/21/03 04:32 AM
Re: Who's using the Ocelot Compiler
|
Brian Raynor
addict
Registered: 01/09/03
Posts: 454
Loc: Columbia, SC
|
I finished up the usage of the System Map for variable and timer names in the decompiler. Works great! Now I just need to have it create automatic constants in the decompiler for things like touch objects, etc...
Actually, I'm thinking about modifying the language a bit to add definition types for things like touch_objects, icons, etc. Really these would still be constants (and could be used as such), but it would make the program output by the decompiler much more legible.
One thing this will allow, which is another "feature" I'm considering adding to the compiler, is the ability to have the compiler write out a System Map based on the oclc program. In order for that to work, the oclc source code needs to be able to identify touch objects, icons, etc from one another (and not just as general constants). I'm hoping that this should be fairly easy.
I also working to fix the compiler so that if you tell it to include original comments that it will work and not put them in the output twice (this switch was disabled, but after it being turned out does the output twice).
I didn't get all the chances I wanted to clean up the code a bit so i could post it to Source Forge (I like spending a bit of time doing diffs to make sure I didn't mess anything new along the way before checking stuff in as well). Once I get that done (probably the end of the week unfortunately. I'll check in the new functionality.
Send me an email (or a private here) if you want the executable in the meantime. Would love to have someone do a little testing of it. Main thing that changed was the decompiler. Only minor fixes/additions to the compiler.
|
|
Top
|
|
|
|
|
#12959 - 08/23/03 07:18 AM
Re: Who's using the Ocelot Compiler
|
Brian Raynor
addict
Registered: 01/09/03
Posts: 454
Loc: Columbia, SC
|
Nathan,
If you're interested, please send me an email. I was planning on putting an updated version on SourceForge, but I've been focusing on completing the functionality verus pretty-ing it up right now (that will come).
Biggest advantage of the compiler is the ability to use a standard text editor to easily modify a program, search/replace, etc... Also macro capabilities, alias, etc. I find it a lot faster to develop programs using a text editor than using CMAX, and much easier to debug as well.
The compiler was originally written by David Alden, and then modified to provide some CMAX 2.0 support by Patrick Hurley (he also added named label support!). I have since added 2-way support for the ADI System Map (more on that later) as well as extended the language a bit, fixed some bugs, etc...
Basically the compiler takes a C-like language and can compile it into CMAX code (ie: a .PGM file). There is also a decompiler enclosed that will take a .PGM file and create source code for the compiler.
Thus, you can go both ways (for the most part) with the compiler. The compiler also supports macros that will let you create "pseudo-functions" if you use the same type of code a lot in your program. Of course, this will simply expand out in the CMAX program output (since CMAX doesn't support functions and so forth).
The original compiler that supported CMAX 2.0 (that Patrick modified) is available on http://sourceforge.net/projects/oclc . I have not yet checked in all my changes (and they are very significant), but would be happy to send you a compiled copy of the compiler and decompiler to test if you like, with the understanding that it is not fully polished yet.
Here's a few things I have currently added to the compiler (these are working):
- Support for using the System Map to automatically name variables and timers in the decompiler.
- Support for having the compiler generate a System Map as output with variable and timer names in the System Map, as used in your source program.
- New types including icon, ir_code, x10, ascii_msg, and button. These will allow you to define these types in a program, and use them as constants. The neat thing is that if you tell the compiler to create a System Map, it will automatically put the names you specify in the System Map under the correct section.
- Various fixes to various problems in compiling and decompiling some of the various different functions.
The following are things I am currently working on adding:
- Allowing the decompiler to automatically create icon, button, ascii_msg, etc. declarations from what is in the System Map.
- Ability to have labels defined in the original CMAX program in comments (ie: if comment starts with ":MyLabel" then MyLabel will be associated with that line when decompiled). This will allow you to make changes using CMAX and then have the compiler and decompiler automatically "fix up" your Skip to statements (this is if you'd rather develop using CMAX than the compiler). This is nice as in CMAX if I have 10 different places jumping to the same point in a program, and now I want all 10 to jump somewhere else I must manually change all of them (ensuring I get them right). With the label thing, you simply change in the comment where the label points, and run a quick decompile and compile and it will fix it for you (in theory, not fully implemented yet).
- Fixing ability of compiler to use original comments in the source in the generated PGM file. This capability is there, but there are some flaws in the way it puts the comments (on the wrong line sometimes, etc).
- New types for the definition of modules (ie: secu16, slave ocelot and leopards, bobcats, etc). Not sure yet how to do this. Main reason for this is so that compiler can create a new System Map based on the program (ie: a .PRJ file).
As an example, here's some sample source code (please note that this is a test program that really doesn't do much useful - just to test the compiler):
[CODE]variable(58) bob;
constant relay1 = "1/8";
constant ir_selectVideo1 = 71;
constant zero = 0;
x10("D/1") bedroom_lamp;
x10("A/1") x10_selectVideo1;
ir_code(71) ir_selectVideo1;
ir_code(10) ir_tvPowerOn;
ir_code(12) ir_tvVideo1;
ir_code(13) ir_tvVideo2;
// Variable Definitions
variable watching = ir_tvVideo2;
variable(60) last_received_ir;
variable(61) leopard_beep;
// Timer Definitions
timer sleep = zero;
timer(2) timer_no_2 = zero;
macro turnOnBedroomTV(number which_input) {
transmit_ir(0, 0, ir_tvPowerOn);
transmit_ir(0, 0, which_input);
watching = which_input;
sleep = 1;
}
macro relay_on(string which_one) {
module_point(which_one, "Turns ON");
}
macro testEmptyParameterList() { // this line tests empty parameter lists
x10_quick_on(bedroom_lamp);
}
if (last_received_ir = 65535) { // Received invalid IR command
transmit_x10("A/1");
relay_on(relay1);
}
if (receive_x10(x10_selectVideo1) ||
receive_ir(ir_selectVideo1)) {
turnOnBedroomTV(ir_tvVideo1);
# Here we go, I sure hope the following works!
testEmptyParameterList();
testEmptyParameterList();
transmit_x10("C/21");
testEmptyParameterList();
transmit_x10("C/21", 3);
testEmptyParameterList();
testEmptyParameterList();
transmit_x10("D", 22, 5);
transmit_x10("F/3");
transmit_x10("G", 4);
#set_slave_variable("Ocelot", 2, 23, 32700);
#set_slave_variable("Leopard", 3, 24, 32701);
set_slave_variable(2, 23, 32700);
set_slave_variable(3, 24, 32701);
load_data_to(bob);
timer_no_2 = 1;
bob = 3;
leopard_beep = 5;
send_rcs_x10("A", "setpoint", 99);
send_rcs_x10("A", "DT3");
send_rcs_x10("P", "Request Temperature");
send_bobcat_thermostat(2, "Setpoint", 54);
send_bobcat_thermostat(2, "Fan Mode Auto");
send_bobcat_thermostat(63, "Hold Release");
}[/CODE]Send me an email if you'd like to try what I have now (just drop me a private message to my profile telling me your email address). Progress of development has been a bit slow because of life getting in the way (ie: work, family, etc!!!). But of course all that is MUCH more important.
However, I am still quite satisfied with how the compiler is working out...
|
|
Top
|
|
|
|
|
#12960 - 09/14/03 07:37 AM
Re: Who's using the Ocelot Compiler
|
Neil Cherry
junior
Registered: 01/17/03
Posts: 37
|
Brian, I'd like to get a copy of your latest code. I tried sending you an email via the forum but that failed. Can you email it to me (ncherry@comcast.net)? Once I get it may I post it to my Linux HA web pages
Thanks
|
|
Top
|
|
|
|
|
#12963 - 09/21/03 07:32 AM
Re: Who's using the Ocelot Compiler
|
Neil Cherry
junior
Registered: 01/17/03
Posts: 37
|
Thanks Brian, I've received the software and I won't post it. It will be a while before I can work with it as I'm going nuts between school and work (I expected this).
|
|
Top
|
|
|
|
|
#12964 - 11/26/03 03:00 PM
Re: Who's using the Ocelot Compiler
|
David Norwood
newbie
Registered: 11/20/03
Posts: 11
Loc: Thousand Oaks, CA
|
I'm still using oclc 2.0 and xalib to upload my programs. It works great and I'm glad to see development continuing.
|
|
Top
|
|
|
|
|
#12966 - 03/31/04 08:12 PM
Re: Who's using the Ocelot Compiler
|
MrChuck
newbie
Registered: 02/27/04
Posts: 4
Loc: berkeley, ca
|
Well, I found this yesterday at
http://www.math.ohio-state.edu/~alden/ocelot/compiler.html
and pulled down "2.10b4.tar.gz" (beta 4 of 2.10?) dated May 28, 2002. (22 months ago).
It compiled up on a Mac OS 10.3 (current sub updates).
Seemed to work - it compiled fine. It compiled the test files just fine into .pgm files. (haven't loaded to the ocelot).
It also compiles fine on Mac OS 10.2 (another laptop). (bison 1.28 on 10.2 and 10.3).
The bison phase utterly failed on FreeBSD 5.2.1. (bison 1.75)
Now, I go to http://oclc.sf.net and download the "newer" version - 2.5b1 (version 2.5 beta 1, which appears updated to the 2.10 version I previously had. My head hurts on versioning.
On all the machines (mac 10.3/10.2 and FreeBSD 5.21), it utterly fails in the bison.
Aha! Using yacc, it works just fine.
So 2 questions:
1) versioning. 2.10 appears to be older than 2.5.
If there's a fork, can it get an altered name?
2) Anyone else seeing bison parsing issues?
And if you're failing on that, run
make
byacc -d oclc.y
make
and all is fine (or mv bison before ./configure).
Now to get it to upload from a FreeBSD box.
|
|
Top
|
|
|
|
Moderator: Dan Smith, Monte G, ADI Tech Support, Guy Lavoie
|
1 registered
(dasdasd)
and 17 anonymous users online.
|
|
2765 Members
19 Forums
3856 Topics
22808 Posts
Max Online: 67 @ 08/16/11 03:08 PM
|
|
|
.
