1 |
On 01/26/2011 12:56 PM, Mark Knecht wrote: |
2 |
> Michael, |
3 |
> Thanks for the inputs. It gives me more to think about. |
4 |
> |
5 |
> In this case the input language is interpreted, not compiled. The |
6 |
> trading platform interprets the program and internally turns it into |
7 |
> buy & sell operations. (Not the piece of code I supplied - that was |
8 |
> just a small function.) Unfortunately, as the language is proprietary |
9 |
> to the trading platform there isn't a way to go to any common |
10 |
> low-level language. |
11 |
> |
12 |
> The 'battery of tests' would be, I think, the trading program being |
13 |
> executed on a certain market, producing a certainly list of buy & sell |
14 |
> operations and a specific gain or loss. It would be quite easy to |
15 |
> compare the outcome because it's nothing more than a list of trades. |
16 |
> If the translated code generates the same list then it works. If not, |
17 |
> I dig into why. This part of the task seems relatively straight |
18 |
> forward to me. |
19 |
> |
20 |
> I was mainly hoping to find a tool that might generate _reasonable_ |
21 |
> C code, even if it's not perfect. If the C code compiles and runs then |
22 |
> I could determine what works, what doesn't, and start fixing things. |
23 |
> I'm not a C programmer and haven't touched that language in at least |
24 |
> 15 years so anything that moves me forward would be helpful. |
25 |
> |
26 |
> Again, I do appreciate your inputs. If this extra info gives you |
27 |
> any new ideas please let me know. |
28 |
|
29 |
If you don't even have a common low-level language, what you're |
30 |
essentially doing is creating a compiler for EasyLanguage. Take a small |
31 |
example, adding two integers in E.L. I won't pretend to know the syntax, |
32 |
but let's just assume that you have two integers (or numbers or |
33 |
whatever) 'a' and 'b' declared. |
34 |
|
35 |
How do you translate "a+b" to C code? You can declare two ints 'a' and |
36 |
'b' in C, of course. But these are 32- or 64-bit integers. So if 'a' and |
37 |
'b' are large, "a+b" will overflow. Do EasyLanguage integers work that |
38 |
way? Probably not... |
39 |
|
40 |
How about "a/b"? Does EasyLanguage do integer division, or does it treat |
41 |
them like floats? If it does treat them like floats, do the rounding and |
42 |
precision agree with C floats? Probably not, so floats are out too. |
43 |
|
44 |
If you try to fix all of these problems, what you'll end up with is |
45 |
something like a struct EasyLanguageInteger {...} with associated |
46 |
functions add_easylanguage_integers, divide_easylanguage_integers, etc. |
47 |
Then, you can translate "a+b" into add_easylanguage_integers(a, b) where |
48 |
'a' and 'b' are now structs instead of just ints or floats. |
49 |
|
50 |
Then, you'll have to write a parser that understands the rules of |
51 |
precedence, looping constructs, functions, and everything else so that |
52 |
they can be converted into the appropriate structs and function calls. |
53 |
At the end, if it works, you'll have an EasyLanguage compiler. |
54 |
|
55 |
Without a spec (the language is proprietary?), you'd have to guess at |
56 |
most of that stuff anyway, so the chances you'd get it all right are |
57 |
about zero. |
58 |
|
59 |
Your best bet[1] is to create a ton of test data, and feed it to the |
60 |
E.L. program. Make sure the test data triggers any edge cases. Then you |
61 |
can attempt to rewrite the code in C, and compare the output. You as a |
62 |
human who understands what the code does can take a lot of shortcuts |
63 |
that a translator couldn't. |
64 |
|
65 |
|
66 |
[1] I'm assuming you want to do this for a relatively small number of |
67 |
programs, and that writing a compiler would not actually be less |
68 |
time-consuming. |