Survey posted 2005-02-15 17:43 by Jon.

Contribute ideas to surveys by sending a mail to survey@ticalc.org.

Sdcc would be a nice start, but it's not really windows friendly (needs cygwin if I'm not mistaken). Anyway, having a c compiler could be nice if you want to make a quick proof of concept, but these calcs don't have a lot of ram and aren't that fast, so asm is always going to be a lot better and z80 isn't such a difficult language.

There are more languages than Assembly, C and TI-Basic... How about a Pascal compiler? I don't want to start a flamewar (of course, there is no need for this compiler to run on anything but Linux, that goes without saying ;) ), but I think Pascal has some serious benefits.
At the moment, I lack both the time and the required skills to make it myself. On the other hand, I've been planning to make this program for quite some time now, sooner or later it just might actually happen. Anyway, I guess this is as good a time as any to ask if anybody would actually use such a program. Would I make anyone happy with this, or only cause people to wonder "Why Pascal of all languages?"?

Yes, I don't see why we have to be tied into C. Granted, I don't know Pascal nor do I intend to learn it unless I have to. However, a JRE for *all* the calculators (even it it just supports basic stuff; that is, just java.lang.* and java.Math.*) would be nice to poke around with... Of course, you'll need a *.class to *.??<v|p|s> converter, but that's trivial.

C is one of the most efficient programing language, that's why it is the language of choice one calculators for the people that can't program in assembly.

I agree with this guy, a C compiler would be very nice, think what if we ever come up with a TI Modem (I seriously doubt it, what would be the point?) and we dont have any scripts to make it connect! C would work obviously and we could also learn C instead of ASM (which only works for calculators whereas C is for computers and calcs if we ever get a C compiler going) but ASM is going to be hard to kick off of its reign no matter what you get running on a z80!

I think I remember BurntFuse saying that he had layouts or something along that line for a functional TI-Modem :).

Yeah, sort of a general block diagram/electrical schematic with the different chips and data paths and scripts and stuff. It'll probably be at least a year before I get around to actually trying it out. :-/

As far as computers go, C is old school (unless you're doing low-level stuff)! Why not something like Python, Tcl, or Perl?

C is much faster for a given compiler complexity. It is possible to make a BASIC (or whatever else) compiler that generates lightning fast code, but it is much harder (mainly because C is much closer to the most machine languages).

C is actually quite simmilar to z80 Assembly. I often find myself poring C routines/code to z80 Asm, just because it's easier than re-writing the asm code.
*End Plug*

haha, that's funny. Java on a calculator! Sorry, but if Java could run at all, it would most likely be even slower than BASIC. Java is the most bloated language ever. Try running a simple "Hello, world!" program in Java on your computer. Look in the task manager and see how much RAM it takes. Java uses up huge amounts of system resources to incorporate all of the features that make it what it is, a safe, portable language. In addition to the JRE which catches exceptions and causes no kind of crash for you computer, the garbage collector frees memory for you, and it is constantly making things work smoothly and portably. In order to run Java on a calc, you would need to take all of that away because you cant use those resources, and essentially what would be left is C. IMHO, C is the epitome of languages. It contains just what you need to do anything, and do it fast. Really fast. C++ is great, but there is nothing you can do in C++ that you can't do as fast or faster in C with a little more work, just like there is nothing in C you can't do as fast or faster in assembly, but assembly is in many ways a difficult language, and every processor has its own, whereas C is universal, more or less.

I'm going to add some stuff to basicly explain why Java will never run on a z80 processor.

First, Java bytecode has 4 primatives, Ints (32-bit), Longs (64-bit), Floats (32-bit) and Doubles (64-bit) Even if you were to just not suppor the float and doubles, which would avoid you having to write library calls to handle IEEE floating-point math, you're faced with the problem of having to perform 32-bit math in the simplest of situations. If you say "byte b;" in Java, it allocates a whole 32-bits. There is nothing smaller for it to use.

Next up, Java bytecode to allow for addressed local-variables works by providing a short worth of addressable 32-bit values, which are effectively used in a non-managed flat array. With means you have 65,536 * 32-bits = 256KiB of memory required available for each Java method. Last I checked (looks some stuff up) yep. The Z80 calculators still don't have that much memory available.

So basicly, Java having been designed to be Machine-Independent is actually quite dependant on the processor being capable of performing efficient 32-bit math, along with IEEE math in both single and double percision.

I also find that you have a confused opinion about the speed of languages. Be it known, that rarely with modern machines can a human produce the same quality of code in assembly that a compiler can. A good example, I was working on AltiVec, and the compiler produced into assembly two instructions that accomplish the same task, put a value of 1 into each word element of the vector as a constant value. Why did it do this? Because due to scheduling it could actually perform the two actions simultaneously. A human would have to be quite well versed in assembly and timing diagrams and optimization techniques to produce the same code (which will not btw, run any faster)

Java has also been shown to be little slower than C++ when using the JITC interface, and in fact, occationally faster. Java is no-longer the slow laboring beast that it once was. Now, I still don't like the language for reasons entirely appart from speed or anything like that. I don't like the language, and I don't like the wrongful claims made about it. (note: Speed has never been a claim of Java, but interoperability, and platform neutrality has. I've had less problem with writing portable C, than with writing Java that behaves properly on multiple operating systems)

In fact, since the memory allocation interface is implemented in the Java Bytecode, there is literally no way to just throw out the garbage collector. The bytecode is literally dependant on it.

It depends on the platform...maybe sometimes on a computer, a compiler can produce better code than a human, but on a calculator, there are no dual pipelines or anything like that, so a human with experience can produce better code than a compiler.

C++ is much better. There are many shortcuts you can do that save time and effort.

#include<iostream.h>
#include<conio.h>
int main()
{
clrscr();
int x=0;
while(x <= 9)
{
cout << x;
x++;
}
getch();
return 0;
}

the output would be:
0123456789

I want to see you do "x++", "x--", or "x+=1" in C.

Here (compiles with gcc; written from 'Using Turbo C'):
#include <stdio.h>

main() {
char x;
for(x=0; x<10; x++) {
printf("%d", x);
}
printf("\n");
}
The truth is, x++ comes from C, so that refutes your claim.

I would love to see one for most Z80's, at least the flashable ones.

Why does (almost) everyone ignore the non-flash calcs? (Maybe TI's pro-flash marketing for the purpose of getting people to spend more money on the newer models?) The '86 deserves a Z80 compiler just as much as the '83+. :-p

Sorry, nothing personal.

C is super bloated code, especially with the current crop of compilers that can't optimize code.

I would love to see a C compiler for the TI-86, & it has more RAM than the other non-flash Z80-based calculators, so it would fit space bloat (but not much speed bloat - then again, neither would the 68000-based ones, & there are C compilers for them). On an unrelated note, a TI-86+ (with flash) would be really cool. I would almost certainly buy one.

I would too - but not as a separate storage area like on the 83+, instead where all the data from the RAM is backed up when the calc is turned off and restored when the calc is turned on, so users and assembly programs wouldn't have to deal with the pain of archiving, unarchiving, garbage collects, etc.

Considering the number of times I turn my calculator on & off, the flash would wear out too quickly (it only has 10,000-1,000,000 rewrites, usually). Plus, my calculator sometimes crashes when I hit 2nd-off. :) MRAM (magnetic RAM) would be really cool. >1,000,000,000,000,000 rewrites, & it can be used like RAM, but keeps data like (E)EPROM or flash.

OK then, you could select a "backup" or "restore" option on the memory menu. Or on the subject of alternate memory technologies, it could use FRAM or FeRAM or whatever it's called...now we just have to wait until they can make chips with it in decent densities... ;-)

The same compiler ought to work for all z80 models, seeing as they share a processor...

I'm not an ASM pro, but the rom calls might be diffrent between the calcs. There are also key location difernces. Especially between non-flash and flash.

There are MANY differences between the different calculators - that's why there would be an option in the compiler to select the calc model.