| ??? 08/11/08 17:53 Read: times |
#157406 - Doesn't seem to be a C to I2L Responding to: ???'s previous message |
Richard Erlacher said:
Maybe it's just a question of choosing the correct ARM. LPC2387 (same processor but with 40kB extra RAM and 256kB extra flash) is probably the only ARM change that is reasonable to look at. New conformance tests (emission, temperature, vibration, ...) can easily cost $200.000. That on top of the hardware redesign and porting of the current code. Anyway - no need to look at a different ARM until I have ssen a problem with the current one. Richard Erlacher said:
I don't know much about JAVA. How frugal is it with its memory resources? Not at all. It's much to hungry for my specific needs. Richard Erlacher said:
It's my guess that the I2L fell away when CPU's became larger than the intermediate architecture, as the I2L instructions became a subset of 68020 or Pentium. If you contact Loren Blaney (or any of the other "actives") of the Denver Area 6502 users' group, he can fill you in. There may even be a tool for translating between 'C' and XPL0, though I'm not sure it goes in both directions or in which direction it translates. In my view, it would be useful to be able to translate in either direction, so code can be written i 'C' and converted to XPL0 for final debug, and written in XPL0 and then converted to 'C' for informal verification or whatever. It "sounds" to me as though this might be an avenue for you to pursue, as the I2L code is normally quite compact, and the I2L interpreter is said (by others) to be quite straightforward to generate. I mention this because there was an earlier mention of BASIC, which has often come up in discussions regarding XPL0, and XPL0 has always "come out on top." Reverse-engineering from the byte-code of an abstract virtual machine is not so much easier than reverse-engineering for the machine code of a normal processor. The compilation step is inherrently lossy. There are algorithms (for example Browns algorithm - don't know any link) that allows a few markers to be added to a RPN stream to allow restoration of the source excluding comments and original indentation. This is a good solution in a spread-sheet, where you can store the formulas as byte-code and then restore a text-based formula for further editing. It isn't practical for a real programming language since comments and named constants are so vital. |
| Topic | Author | Date |
| Virtual or existing architecture for emulation | 01/01/70 00:00 | |
| Additional info about host/usage | 01/01/70 00:00 | |
| How about MIPS? | 01/01/70 00:00 | |
| VHDL | 01/01/70 00:00 | |
| take a look at the content | 01/01/70 00:00 | |
| I think 8 or 16 bit is optimum | 01/01/70 00:00 | |
| Maybe you should start with an ARM chip | 01/01/70 00:00 | |
| I2L sounds interesting | 01/01/70 00:00 | |
| It's probably best to check with the maintainers | 01/01/70 00:00 | |
| Doesn't seem to be a C to I2L | 01/01/70 00:00 | |
| The LLVM Compiler Infrastructure | 01/01/70 00:00 | |
| Since there's help available ... | 01/01/70 00:00 | |
| With the low price of 8-bit single chip MCUs... | 01/01/70 00:00 | |
| Slave processors not an alternative | 01/01/70 00:00 | |
| Users | 01/01/70 00:00 | |
| Probably debugging on PC | 01/01/70 00:00 | |
| Are you really going to do that! | 01/01/70 00:00 | |
| Existing building blocks helps | 01/01/70 00:00 | |
It hasn't been done for you but ... | 01/01/70 00:00 | |
| When I was in school ... | 01/01/70 00:00 |