SirCmpwn wrote:
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.
Nifty, that's more or less the more complete and complex version that I was thinking you might have done, so kudos for that. It's certainly understandable that it's still quite amorphic; I wish you lots of luck in solidifying the concept and design.
Thank you very much. I wanted the most flexible code I could get.
And it is most definitely still amorphic, there is still a ton to do.
SirCmpwn wrote:
Thank you very much. I wanted the most flexible code I could get.
And it is most definitely still amorphic, there is still a ton to do.
What kinds of C#-y things are you thinking of supporting, in terms of math, GUIness, CLI things, etc?
Math, I plan to support all primitives (byte, short, ushort, int, uint, long, ulong, float, double), and all operations on each (+, -, *, /, %). I will also probably replicate the System.Math library in .NET for this, to add functions like power and square root.
GUI-ness, I plan on porting the DCS7 GUI libraries, and of course, the KOS libs.
CLI, none.
I will try to convert as much of the .NET framework as possible to work.
SirCmpwn wrote:
Math, I plan to support all primitives (byte, short, ushort, int, uint, long, ulong, float, double), and all operations on each (+, -, *, /, %). I will also probably replicate the System.Math library in .NET for this, to add functions like power and square root.
GUI-ness, I plan on porting the DCS7 GUI libraries, and of course, the KOS libs.
CLI, none.
I will try to convert as much of the .NET framework as possible to work.
It sounds like you've put a lot of thought into this; I just hope it doesn't distract you too much from all your other projects. Does porting the DCS7 GUI libraries mean recreating the libraries themselves, or assembling programs to be run under DCS?
so, if I am understanding this right, you are going to have support for all types of variables?
qazz42 wrote:
so, if I am understanding this right, you are going to have support for all types of variables?
All types of primitives, and I'd imagine some simple classes such as strings as well.
qazz42 wrote:
C# now compiles itself XD
It already does; see System.Reflection.Emit (you can use this to add scripting to your program, for example).
SirCmpwn wrote:
Math, I plan to support all primitives (byte, short, ushort, int, uint, long, ulong, float, double), and all operations on each (+, -, *, /, %).
Don't forget sbyte, though of course none of sbyte, ushort, uint and ulong are CLS compliant. bool would be pretty handy as well.
SirCmpwn wrote:
It compiles to asm, sorry to disappoint
I seriously don't think that Reflector is an option here
However, as CIL is still relatively high-level, you can comparatively easily turn this back into C# or VB.NET source code (for example). Hence my suggestion of a workaround being to develop an application in (say) VB.NET, then run that through Reflector to translate it into C#, then to compile that with your compiler.
I still think going from CIL to Z80 makes more sense than going straight from C# to Z80, though. 
Good luck!
the main reason that I am <3ing this is that I can understand the code O_O
the hello world in C and asm kinda confuse me.. (long story with the C example) but this... this I understand everything
EDIT: How would one use getkey in this C#?
qazz42, the return type is an int, but will eventually be a TIOS.KeyCode (enum)
benryves, CIL to Z80 sounds nice, but I have some things I want to add to the language for z80, like hex methods. Also, there are some features of C# I don't want to implement yet, such as generics, dynamic objects, and linq, that I couldn't restrict.
I forgot about sbyte and bool, thank you.
As for DCS, I'm going to convert the include file, basically.
SirCmpwn wrote:
benryves, CIL to Z80 sounds nice, but I have some things I want to add to the language for z80, like hex methods.
What do you mean by "hex methods"?
There would be nothing stopping you from displaying an error if the CIL contained something you didn't support (such as generics) in the same way as you could display an error if the source contained something that you didn't support.
Hex methods are methods defined entirely in hex. This is how some of the libraries work.
So inline assembly, but without the actual assembler?
SirCmpwn wrote:
qazz42, the return type is an int, but will eventually be a TIOS.KeyCode (enum)
benryves, CIL to Z80 sounds nice, but I have some things I want to add to the language for z80, like hex methods. Also, there are some features of C# I don't want to implement yet, such as generics, dynamic objects, and linq, that I couldn't restrict.
I forgot about sbyte and bool, thank you.
As for DCS, I'm going to convert the include file, basically.
sounds good then
will you plan to follow the TI-Basic keycodes or make your own?
KeyCode.A, KeyCode.Mode, KeyCode.Sin...
Ah, that is pretty simple
Does this project have a name yet by any chance?
Generally, TIC#. Specifically, the compiler is called ticsc. The standard libraries are called TI.NET.
hmm, I was wonder, roughly how much longer do you think until this will be released? I am just super psyched that there is finally a calc language that is just perfect for me
