I'm learning C++ right now and have heard of people writing programs in C and compiling them as an assembly program. Does anyone know of a compiler that will do this for C++ that is easy to use and actually works?

Another random question: Does PTI support the 84+ series?

Wow, this is a coincidence! I asked this question when I joined (I was a guest then, but oh well). And Kllrnohj pointed out that OOP is too big for calculator use. Look through the section (general programming).

Alright... thanks. I guess I'll just have to continue the agonizing task of improving my assembly skills.

I am waiting for Chipmaster to start on his tutorial so I can help from an ASM noob's standpoint.

If you need any help with c++ just ask Kllrnohj or me (he will help more though)

The C compilers for Z80 suck pretty bad, so you aren't missing much anyway But yeah, OOP is a bloated design albeit its benifits greatly outweigh this disadvantage as we are talking in the kbs of bloat, not nearly large enough to make a noticeable dent in a computers harddrive - now on a calc that only has 24k to begin with, however...

Now what you CAN do is have gcc/g++ output the X86 asm if that will help you re-code functions in Z80 (although that might not help much if you don't know x86 asm )

Sorry. I've been really busy, and sick. I finally have a free day tomorrow (well after school gets out) so I'll get some stuff done then.

What about that SDCC thing?

You remember the InstCirc I got with that? It was 3 times larger than the pure-asm one That, and it used iy, which was a hassle to have to keep resetting it before each bcall

Yeah, but that iy thing is a fault of whoever wrote the parts of SDCC that use iy.

SDCC wasn't designed for TI-calculators, which is why it gets used. There isn't any reason to not use IY except for the stupid reason that the OS has dibs on it, which is a flaw of TI's design

Oh, ok, that makes sense. You can just push iy/pop iy around SDCC code. Anyway, hopefully someone comes up with a better solution, but there's no way it would be able to optimize enough to make it worthwhile over hand-coded ASM/

Kerm: The problem with that is that iy isn't used much by sdcc, so you always have to save it even though it might not be in use (and you can't push/pop because SDCC will push it before the function call, and pop it after - you have no idea what the stack will be like inside of a function call)

That's what I meant. Push iy, do all your SDCC program code, then pop iy right before your exit/return.

iy is also used by bcall's, no? I've heard that it can potentially be used in an interupt, but I'm not positive about that... besides, you can just ld iy anyway, as its always the same value, no need to push/pop it

The big problem is that IY is used by the system interrupt to check various things, namely whether to show the run indicator and if it should scan for keypresses. And, yes, a number of BCALLs also reference IY, but nothing changes it.

Kllrnohj: i is used for interrupts, not iy. It is used to store where the interrupt occurs so that random execution doesn't happen.

What about what Tari said?

Mostly correct. IY is an index register that points to the bytes TI uses to store mode information and various system flags. IY should always point to the beginning of this area so that bit x,(iy+n) checks can be used.

Which is why it has to be reset for bcall's (And potentially in interupts) - I think we've just gone in a circle...