Hello,
I just turned this:
Code: using TIOS;
using TIOS.Drawing;
public class Test
{
public static void Main()
{
Interrupt.DisableRunIndicator();
LCD.Clear();
Home.Up();
Home.WriteLine("Hello World!");
Input.WaitKey();
Home.NewLine();
}
}
Into this: (Download)
Very nice SIr! Can't wait to see the extents of this when you get it done. I can imagine this will be a very powerful language for people who use C or any variant of it. Is it safe to assume that this uses 0 TI OS specific code (you know, except for screen addresses and such)?
Pre-edit: you just answered this actually
Quote:
23:38:21 (C) SirCmpwn: it can
23:38:37 (C) SirCmpwn: it uses TIOS bcalls with this particualar code because its more efficient
The problem is that you're going to fall into the usual calculator trap: not being able to produce as optimized code as a skilled z80 coder, and therefore appealing mostly to new users who might just be using TI-BASIC anyway. Don't get me wrong, it seems nifty, but it's part of my job description to play devil's advocate.
KermMartian wrote:
The problem is that you're going to fall into the usual calculator trap: not being able to produce as optimized code as a skilled z80 coder, and therefore appealing mostly to new users who might just be using TI-BASIC anyway. Don't get me wrong, it seems nifty, but it's part of my job description to play devil's advocate.
D:
I think this looks really great, my kind of language to learn. And yes, I only know a tiny bit of ASM, therefore your statement is correct. Good job predicting that one.
Is CIL involved? That is quite clearly C#, and the thought of a Z80 CLR naturally excites me.
If you are compiling to native code, are you going via CIL or are you going straight to Z80 assembly from C# source? The former has more interesting prospects to my mind - you've already got a good compiler and development environment, you could implement the libraries for the PC as well so could get a decent debugger and - the real beauty of CIL - could target the calculator from a wide variety of languages, not just C#.
Of course, going from C# to Z80 assembly directly is still very cool, and you could get some of the advantages of the above by compiling in <language of choice> then running the generated assemblies through Reflector to translate to C# before compiling again for the calculator.
I look forwards to seeing where this goes!
O_o
holy... crap... now I can program C# and my calc at the same time
O_o I am just surprised, wow, this is amazing
will the two namespaces be downloadable for people who want to beta test?
also, I assume the compiled .cs file must go through another converter to make it a .8xp, am I right?
KermMartian wrote:
The problem is that you're going to fall into the usual calculator trap: not being able to produce as optimized code as a skilled z80 coder, and therefore appealing mostly to new users who might just be using TI-BASIC anyway. Don't get me wrong, it seems nifty, but it's part of my job description to play devil's advocate.
Yeah, that's definitely true. It will auto-optimize things like cp 0, though.
qazz42 wrote:
will the two namespaces be downloadable for people who want to beta test?
also, I assume the compiled .cs file must go through another converter to make it a .8xp, am I right?
1) No. The whole thing should be released soon.
2) No, straight to 8xp, or 8xk, or 8xu.
benryves wrote:
Is CIL involved? That is quite clearly C#, and the thought of a Z80 CLR naturally excites me.
If you are compiling to native code, are you going via CIL or are you going straight to Z80 assembly from C# source? The former has more interesting prospects to my mind - you've already got a good compiler and development environment, you could implement the libraries for the PC as well so could get a decent debugger and - the real beauty of CIL - could target the calculator from a wide variety of languages, not just C#.
Of course, going from C# to Z80 assembly directly is still very cool, and you could get some of the advantages of the above by compiling in <language of choice> then running the generated assemblies through Reflector to translate to C# before compiling again for the calculator.
I look forwards to seeing where this goes!
It compiles to asm, sorry to disappoint 
I seriously don't think that Reflector is an option here
Quote:
1) No. The whole thing should be released soon.
2) No, straight to 8xp, or 8xk, or 8xu.
wow. straight to 8x*? Holy a man!
now, what would be the line of code needed to state weather it needs to be a app/program? or are you not that far yet? (sorry if I seem pushy tho, I am just ever so curious because this is better than C programing to me )
Not a line of code, a command line argument.
ah, ok, I get what you are saying
good luck with this SirC, I will await a release
SirCmpwn wrote:
2) No, straight to 8xp, or 8xk, or 8xu.
Does it use an assembler of your own design, some existing assembler like SPASM or Brass, or the user's choice between those options? IE, does it generate the asm code and then pass it off to assemble it, or does it generate straight hex?
It generates straight hex. Actually, not even that. It generates a byte array which is passed into one of my utility methods that creates an 8xp.
SirCmpwn wrote:
It generates straight hex. Actually, not even that. It generates a byte array which is passed into one of my utility methods that creates an 8xp.
Very nice! I must say I'm quite curious how you handle things like string constants; do you insert them inline and jump over them, or do you collect the data at the end of the program and manually link the addresses once you know the size of the program?
Technically, I have four working lists while compiling. One is the executable data, not including subroutines. Literals and subroutines are added into a second list of data. One list keeps track of relative jumps and calls in the executable data, and the last list keeps track of the offsets in the data list. At the end, they are all mashed together.
Keep in mind that this isn't very well defined yet. Library output isn't supported, and I manually made the methods you see in the source above, and only string literals are supported. No variables or math either.
so, it is your own compiler? That is what I would like to know O_o
Yes. I produce raw executable output, not a conversion to asm.
wow. sounds nice
err... this might sound weird, but is this compiler in C# itself? that would be funny
Yes, it is
lol, that is pretty funny in a way
C# now compiles itself XD
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
