??? 11/15/11 17:40 Read: times |
#184748 - I like your thinking Responding to: ???'s previous message |
I really like number two.
Per Westermark said:
2) When target transfer times are very slow, so we don't want external builds and then wait for uploads but instead want to be able to make patch the application directly inside the target. This is a very good point for the embedded world of interpreted languages. However, I would like to add that this point needs to work with something like point 3. Per Westermark said:
3) When there is a big advantage to be able to run self-modifying code... For instance, so what if it takes 1 hour to upload the code and only 1 minute to run. Once the code is developed, there are no more uploads. If it is taking that long to upload perhaps the path taken to achieve the goal is not necessarily the correct one. I do see having a huge advantage with point 2 if the code is constantly being updated every few minutes as excessive uploads would cause the life of the memory holding the program to degrade in some cases. Plus you would not have to have additional hardware to compile and then upload the new code and potentially even halting the embedded application. |
Topic | Author | Date |
Interpreted Languages? | 01/01/70 00:00 | |
Sometimes it's hidden | 01/01/70 00:00 | |
p-code | 01/01/70 00:00 | |
P-code and others | 01/01/70 00:00 | |
interpreter/compiler | 01/01/70 00:00 | |
Debatable | 01/01/70 00:00 | |
Not necessarily machine code | 01/01/70 00:00 | |
Definitely debatable | 01/01/70 00:00 | |
Ofcourse not | 01/01/70 00:00 | |
runtime errors | 01/01/70 00:00 | |
You can't | 01/01/70 00:00 | |
You missed the point! | 01/01/70 00:00 | |
Not always worth it with interpreted languaes | 01/01/70 00:00 | |
I like your thinking | 01/01/70 00:00 | |
Many FORTH implementations are interpreted, aren't they? | 01/01/70 00:00 | |
Forth | 01/01/70 00:00 | |
Maybe a comparison? | 01/01/70 00:00 |