EDIT: This project has changed significantly since this thread started. For information about the current state of this project, view http://tinyurl.com/z80antelope or look toward the end of this thread.

I am designing a language and compiler that will essentially bring the feel of C++/Java (without the mess) to z80 Calculators. Very much the same syntax, but with data-types that suit the z80 better (8 and 16 bit variables); The use of classes to create objects, but WITHOUT all the nasty auto copies and references (essentially C++ classes that behave like C structs).

The goals of the language include (but are not limited to):
- Almost all of the features of OOP (inheritance, polymorphism), but without the kind of overhead that would make it incomparable to assembly programs.
- Nothing built into the language with preconceived ideas about an OS, memory management, or anything beyond of the z80 itself
- No limitations on what can be integrated into the language (via macros, assembly-inlining, include-files, etc.).
- Nothing "automatic" in the sense that hidden and unpredicted things happen (i.e. in C++, simply declaring an object calls a constructor which may call a whole chain of other functions and create a mass of instances of objects ... in Opia, constructors must be explicitly called, and only create static initializations).
- Able to do anything that can be done in assembly, including integrating with other any shells/utils/etc.
- A mix of compiled AND interpreted elements allow some variables, functions, and statements to be pre-evaluated and others to be compiled.
- The output code will be more suited to the z80 processor (as it is used in devices like TI-calculators) than C or C++ would be. The language will be simpler and cleaner than C or C++ would be.

I already have much of it in progress; the compiler currently does one heck of a job analyzes source code (preprocessing, parsing, tokenizing, object-representation of code, resolving references to entities, checks for inter-class-integrity, and it does a darn good job of tracking where errors occur and what exactly they are about). I have stopped coding for a bit because I have some theory to iron out before I start having it convert programs into assembly.

Read more about it (and find other links about it) here:
http://dancookplusplus.blogspot.com/

Any feedback or interest or participation in any way would be greatly appreciated.

email me here: shkaboinka@gmail.com
I had seen your website a few days ago and it looks like a very promising project indeed. It sounds like you have some very good ideas and the simplifications to the language should definitely produce more optimized code than strict C or C++.

How much do you plan to complete in terms of a standard library? I'm sure you will have all the basics like the fundamental operations and probably some print functions, but will more involved things like drawing sprites be part of that library as well or are those going to be developed separately?

It sounds like you have a lot of experience with compilers. I really didn't have any experience when I started Axe Parser. So I made an interesting decision to release it publicly despite not being complete (or even very functional in the early days). Looking back at it, I was very lucky that I so rarely needed to change much syntax at all. It was kind of risky and there were a few times when the community really didn't like some of the necessary changes when I did make them. Defiantly a wise idea to keep it in private until at least the theory is finished.

The Axe Language as basically an advanced system of assembly macros since a majority of the commands are looked up on a chart and inserted as a subroutine or directly inline. This method allows for very loose and sometimes confusing syntax but it is highly optimized for what it is and familiar to BASIC languages. But your language would definitely lead to more organized and readable code with a stricter syntax for sure. Have you decided on a new name by the way?

Anyway, I am looking forward to seeing your progress. Let me know if you've got any betas coming Smile
shkaboinka wrote:
(essentially C++ classes that behave like C structs).


C++ classes *ARE* C structs.

Quote:
- Almost all of the features of OOP (inheritance, polymorphism), but without the kind of overhead that would make it incomparable to assembly programs.


Hahaha, not happening.

Quote:
- Nothing built into the language with preconceived ideas about an OS, memory management, or anything beyond of the z80 itself


Okay, but that is more or less the same as every other language. The whole point of a language is to abstract away OS details. C++ will happily run on the metal without any OS behind it. Same with C - if they couldn't, how do you think people write kernels?

Quote:
- No limitations on what can be integrated into the language (via macros, assembly-inlining, include-files, etc.).


Not really sure what you mean with this.

Quote:
- Able to do anything that can be done in assembly, including integrating with other any shells/utils/etc.


Well sure, that's a given if you allow inline assembly.

Quote:
- A mix of compiled AND interpreted elements allow some variables, functions, and statements to be pre-evaluated and others to be compiled.


Uh, why? That syntax is going to be ugly, and kind of goes against your previous claims of nothing automatic/hidden.

Quote:
- The output code will be more suited to the z80 processor (as it is used in devices like TI-calculators) than C or C++ would be. The language will be simpler and cleaner than C or C++ would be.


No it won't. It sure as hell won't if you have interpreted elements.

Also, how do you plan on doing all this without any access to a malloc/free?
I'll see if I can provide the more positive but still realistic counterpoint to Kllrnohj's arguments. Sidebar, I noticed that you're the same guy who started the Antidisassemblage project back in the day; welcome back! Anywho, I think you have a lot of well-though-out and well-researched ideas here, particularly looking at all of the documentation that you have on your blog. I hold some of Kllrnohj's skepticism, but I'll try to reserve judgement until you have something to show. Smile
First let me say, please don't discredit my claims until I can provide something to support them (then whether I can uphold them will be evident). On the other hand, you have many strong points and I will do my best to answer them. I do understand your motive to be realistic though, so it's my job to either do what I've claimed or accept failure -- and let's leave it at that and let the result stand for itself when that time comes Smile

There is no difference between C structs and C++ classes as for storage of data, but there are major differences in behavior. For example, when a class object declared in C++ "object o;" (assuming "object" is some class), a constructor is called, and (depending on how complex the class is) this simple declaration could generate all kinds of instances and copies just to get things set up. In C, such a declaration is JUST a declaration. That is one thing I meant by hidden & automatic things. Similar things happen when a local var is declared in a function; just try assigning a pointer to a temporary object that automatically destructs when the function closes -- you get a mess. As in C, this will only construct or destruct objects when told to explicitly (to maintain "total control"). Now if I were reading this and not knowing anything about the project, I would say "Dude, if you have to do all that manually, how is it cleaner or simpler than C++?" In all honesty, yes if you are trying to do something complex the code will be more complex; but by cleaner I meant does-what-you-say as opposed to the slew of errors that can come from declaring the wrong thing in the wrong place at the wrong time in C++; and by simpler, I mean that simple statements like "I just need this object and to do that with it" do just that and nothing more complicated than stated (basically the same thing as "cleaner"). I guess we are talking "simpler" and "cleaner" in the sense that assembly would be. To that I would respond, "But dude, trying to do complex OOP stuff manually is NOT simpler or cleaner" -- well think of it this way: Some simple OOP program in C++ could easily involve all the kind of stuff I just talked about (unpredictable number of copies and references made, etc), but basically the same kind of program can be made in assembly WITHOUT all that complex OOP; probably gone about slightly differently, but often the clusters of data are roughly the same. I intend to still use OOP just to make handling such clusters look nicer and have the OOP feel. I feel just this paragraph alone could start an endless debate... but hopefully you see my point, and I do recognize the drawbacks (and you can see).

As for most of the features of OOP without the kind of overhead that makes it incomparable to assembly, that DOES need come clarification: Indeed, any OOP that goes to the extent of allowing polymorphism is definitely going to be less efficient than straight-up assembly. By "comparable" I mean that, if you were to do the equivalent thing in assembly (i.e. instead of using dynamically inherited classes, using function pointers directly when a code segment is coded to work with whichever "behavior" given it), it actually is not that far off! In order to fulfill such a bold claim, restrictions do have to be made: First off, ONLY single inheritance is allowed. I have devised a way to use the Java paradigm of interfaces as well, but that DOES require a bit more overhead. If one were to make code that required a reference to some function and some object to pass to it though, it would be very comparable. In instances where more manual techniques are more efficient, then it's roughly the same as saying that it's wasteful to bother using interfaces etc for the given task -- which is true in general anyway. So "comparable" in that aspect (needlessly complicating one's own program is another thing), but you are definitely right that polymorphism will never be AS efficient as going about a task another way (where that is an option), and nothing keeps the programming from going about it another way Smile

"Nothing built into the language with preconceived ideas..." -- Yes that's correct in many cases; but there are many languages where that does not apply (TI-BASIC, Axe Parser, and BBC Basic all are either geared to work directly with the TIOS and no other way, or come with a who set of built-in tools to "give ya everything you should need" for it to be extensively usable). As of yet, No other language for the z80 TI-Calcs (aside from assembly) compares to all-out computer languages like C or C++; I am comparing to what's already out there for them as alternatives to assembly or BASIC (specifics already named). However, don't the "new" and "delete" commands (and other similar mechanisms) of C++ assume there is some sort of OS to handle memory allocation and that it does it a certain way? C uses malloc, which is an explicity coded function with an explicitly decided way to manage memory; and though it's a language standard, it's not "built in" (i.e. a keyword), and alternatives could be coded. That is the kind of environment I mean to provide.

"No limitations on what can be integrated..." - Yeah, the mostly just means because you can inline assembly code. But to be more specific, I'm designing it such that access to system addresses and routines (on the assembly level; i.e. made in any language) can be tied to variables and functions of my language either directly or with very minimal modifications. Some instances will of course require explicit assembly commands to land things in specific registers, since there are many paradigms of how to "pass values" and there is no one "correct" way that will always work for anything and everything coded in any environment.

"Able to do anything in assembly..." -- I suppose that's exactly what I said above, just worded differently. I admit I was pretty tired and just throwing out whatever I could to describe it, hence the repeat Smile

As far as mixing compiled and interpreted variables, that is a HUGE topic of debate for the language. Heck yes, I've had one heck of a time coming up with a good syntax and conventions, and I admit I don't have every last possible kink ironed out just yet ... but yeah I understand why that sounds like more trouble than it's worth. Quite honestly, most of the time it would not be needed, and many of the things I originally thought it would improve can be improved anyway by using data-flow analysis to coalesce variables and things like that. Mostly it is a convenience feature to be used as an alternative to explicitly hard-coding, say, 100 values that follow a predictable pattern into an array. But the main idea was to create "interpreted functions" that basically act as macros, but can act intelligently about the data given to them. As I said, mostly just a nice feature and an added way to hide nasty assembly statements without having to actually call a function at runtime to use it. Admittedly though, overuse of this feature can create messy and confusing code.

"The output code will be more suited to the z80 than C or C++" -- Yeah that's a bold claim. I cannot do better than either as far as larger computers are concerned, but on the z80 for a TI-calc ... I retract that C cannot do well on it, I'm sure it could (with a ton of tweaking and all kinds of tools made for it), but my biggest win there is essentially restrictions on the primitive types being only 8 or 16 bits, and the way values are passed (without assuming that an OS provides a heap and using stack frames ... bleh!). I know C can pass directly to registers if needed and perhaps NOT use a stack frame to save values in recursive instances, but that requires the programming to know all about that and do it explicitly -- I intend to have such optimizations be a given. I am comparing what a "typical" programmer of a language would do (pass values the normal way using stack frames and wastefully use the "int" type...)

Not all, but much of what I've discussed is in my blog (that's what it is; a place for me to work out all the behind-the-code issues). I am still working on the topic about OOP, and the topic on interpreted entities ... yes that's a mess, I will not deny that, and it takes up 3 posts currently; but that's including a full history of the kinds of ideas I had for it and how it's changed and other particulars I've worked out. If you care to read that but only care about what's "current", skip the "An okay solution" section and down to "A better solution" on the intercompretilation topic.

Instead of stating that "such a thing will never work" (Not sure if you are exactly even doing that, but that picture is getting painted to readers of your post), Is there anyone who is interested in discussing how TO make something like this work? I really feel I have some strong arguments and examples already in place and that I am very close already (see blog). I don't think you are trying to be mean and knock my proposal, you have valid points; I am just trying to explain why (and where/how) I do as well. Thanks.

blog: http://dancookplusplus.blogspot.com

My apologies, I only saw Kllrnohj's post when I replied for some reason.

@Kllrnohj: I hope you don't think I'm trying to argue, I do really appreciate your questions and comments; especially since you seem to know a lot about this kind of thing. I did kinda laugh to myself because, if I recall, you've been a strong critic on my past project (Antidisassemblage) in the past (I DID start before I knew what I was doing and released it before it was close to working properly).

@KermMartian: Well said; that is exactly the viewpoint I expect, and I hope to deliver well to any skepticism or optimism (both are great to have) Very Happy

@quigibo: Hey, thanks! I already told you how impressed I was with Axe and the beauty of its minimalistic nature (using the Basic tokens as source code), so it's great to have someone with similar a experience/project give good feedback. There still are plenty of kinks to hammer out before I get anything released. Honestly, between work and school and pouring over my own theory, I do not expect anything close to a finished product to be released any time soon. The language (as defined by the compiler) will be utterly minimalistic, meaning that not so much as a "print" function will be part of the language. Of course, that is where libraries and standard files come in. That will be another project all its own (or phase 2 of the current one, I suppose). I want this to be as adaptable to z80 as C is to [other systems], but there DEFINITELY will need to be libraries/includes made for this. Basic I/O, Sprites/Graphics, data manipulation, ... Yeah anything can be made for it, but as far as what will become "standard", that I will cross that bridge when I come to it; and hopefully not alone. It is possible that multiple flavors of "standard" will develop (analogous to Linux -- not that this is anything CLOSE to something like Linux). I also forsee libraries being made for tools that already exist. There could be libraries just for Mirage, or just for Doors, or just for Bob's-Amazing-thingamajig-toolkit. In other words, with the right tools, this can be used to code any subset of z80 programs normally coded in assembly.

...Oh and KermMartian, if you could make a counterpoint, that would be amazing. Ever since I've had this project (or the past one), the only kind of feedback I have ever gotten was "That sounds great and amazing; but it's over my head and I cannot talk theory with you", or "That will never work because [your claims are bogus] / [I have solid reasoning against it (and am not open to the possibility of that being fixed/improved to an acceptable level to meet your claims/vision)]". The only people apt to grasp all my theory in the past have either been uninterested or dismissive or in disbelief. I've not been able to establish much credibility in the community yet, so I am really hoping I can find that here (and recognize that that may not come until I have something solid to deliver). Thanks
[Just a point of order and etiquette- multiple posts in a row inside about 20-24 hours are considered bad form here; I combined your triple-post into a single one. Please try to edit in such a case. Bumps after a reasonable amount of time are acceptable]
Wow I haven't see you in a long while.

I'm glad you are still around and working on a new language project.

I cannot criticize much on the project content/feasibility because I do not know much about that stuff, but from the experience I have in the TI community (I've been around for 9 years minus 4 days by now), I saw many language projects fail (or released before they work properly). Often, the language was too cryptic/hard to understand, the editor was a major PITA to use or the author was too ambitious for his programming/planning skills.

In Quigibo case, I recommended him when he talked to me about Axe to wait a little bit before releasing any Alpha version and announcing the project. I felt it was too early given what was done and today in the community, people won't take projects as seriously if they are announced in very early stages. Quigibo waited until a decent amount of commands before announcing Axe Parser and now look where the project is.

Another thing: I do not want to discourage you, but since Axe is rather easy to learn for BASIC programmers (the syntax is almost identical for certain programs), that it's programmed under the TI-BASIC editor, compiled on-calc and already very functional without much bugs, it will be very hard to compete against Axe language with a new language project. If you check http://www.omnimaga.org, Axe Parser sub-forum alone had 5634 posts in 5 months and if we include projects on that site, it's 6715 if I forgot nothing. This is 1343 a month. Even on Omnimaga, which is generally more open-minded towards every kind of project aimed towards game programming or game themselves, you would need to make a language that is either as easy, as reliable, as fast, as small (compiled) and that allows as much freedom as Axe Parser, otherwise your language would need to use a syntax very similar to popular computer languages to get a large audience.

See BBC Basic, for example: pretty solid language APP Benryves did there last year, but the hard-to-use on-calc editor killed its popularity.

Regardless, I hope this project goes towards the right direction and I wish you good luck. Smile
Thanks for combining them; that's better (I will be more careful in the future).

Yes, I cannot compete with Axe there. And thanks for the tip; I will be more patient in getting a following ... I suppose I was looking to see if anyone wanted to help with theory or something, especially if any such intend to make use of it.

My approach is to use a syntax very similar to popular languages; a mix of C/C++ and Java, with my own conventions for some things. A code snippet might look similar to this (this example is just a bunch of random stuff, nothing useful):
---------------------
#include "someOtherFile";
use someNameSpace.someInnerEntity;
using someNameSpace;

class MyClass {
public char thing1;
private bool someFlag;

public myClass(char initValue) {
// This a comment inside a constructor
thing1 = initValue;
someFlag = false;
}

public foo() { /* another comment */ }
}


MyClass blar = MyClass('B'); // this is a STATIC initialization
MyClass moo;
moo = MyClass('M'); // and so is this; essentially moo_var: .DB 'M',0

void main() {
blar.foo();
blar.thing1 = moo.thing1;

byte a;
byte@"explicitSystemAddress" cursorRow;
cursorRow = 5; // I just moved the TIOS cursor-row
}
---------------------

More examples are shown on my blog
Yeah, I think this would attract a different group of programmers than would Axe. Axe has mostly been taken up by BASIC programmers and very few ASM programmers currently use it. A language like yours would attract more from the assembly crowd as well as those who have little calculator programming experience but who are familiar with Java, C++, VB, etc.

I probably wouldn't be much help in terms of the theory stuff but I'm very good at asm optimizations and you are welcome to use any of my assembly commands when you get to developing your own standard library.

Also:
Quote:
- Nothing built into the language with preconceived ideas about an OS, memory management, or anything beyond of the z80 itself

Isn't that specialization a good thing though? I mean, if you're making a compiler for z80 on the TI then shouldn't it optimize by integrating the operating system bcalls? While its true you can have faster routines created from source, that takes a lot of extra memory in the program and usually the OS's routines are already sufficient. Are you planning to expand this beyond just the z80 platform?
shkaboinka wrote:
There is no difference between C structs and C++ classes as for storage of data, but there are major differences in behavior. For example, when a class object declared in C++ "object o;" (assuming "object" is some class), a constructor is called, and (depending on how complex the class is) this simple declaration could generate all kinds of instances and copies just to get things set up. In C, such a declaration is JUST a declaration.


Actually, in both cases the object is allocated on the stack, the difference being the C++ will automatically initialize it (a Good Thing), whereas C just lets it sit on whatever garbage was already there.

If you don't want the constructor invoked, then use "object *o;" - problem solved Wink

Quote:
Similar things happen when a local var is declared in a function; just try assigning a pointer to a temporary object that automatically destructs when the function closes -- you get a mess.


As will you in C, because you've returned a pointer to a variable on the stack. To avoid that you only have two options:

1) Don't allow pointers
2) Don't allow stack variables

Unfortunately, you can't do either of those.

Quote:
As in C, this will only construct or destruct objects when told to explicitly (to maintain "total control"). Now if I were reading this and not knowing anything about the project, I would say "Dude, if you have to do all that manually, how is it cleaner or simpler than C++?" In all honesty, yes if you are trying to do something complex the code will be more complex; but by cleaner I meant does-what-you-say as opposed to the slew of errors that can come from declaring the wrong thing in the wrong place at the wrong time in C++; and by simpler, I mean that simple statements like "I just need this object and to do that with it" do just that and nothing more complicated than stated (basically the same thing as "cleaner"). I guess we are talking "simpler" and "cleaner" in the sense that assembly would be. To that I would respond, "But dude, trying to do complex OOP stuff manually is NOT simpler or cleaner" -- well think of it this way: Some simple OOP program in C++ could easily involve all the kind of stuff I just talked about (unpredictable number of copies and references made, etc), but basically the same kind of program can be made in assembly WITHOUT all that complex OOP; probably gone about slightly differently, but often the clusters of data are roughly the same. I intend to still use OOP just to make handling such clusters look nicer and have the OOP feel. I feel just this paragraph alone could start an endless debate... but hopefully you see my point, and I do recognize the drawbacks (and you can see).


I disagree with a bulk of this. You need to decide upfront if you are doing a low level language (developer does everything) or a higher level OOP language (compiler automatically does things). It sounds to me like you are trying to smash the two together - which is just going to suck to develop for.

I strongly encourage you to go for high level compiler does as much as possible, because you are competing with assembly. You are going to lose on speed, pure and simple. You are going to get *destroyed* on that front, so the only chance this language has if it is high level enough that it is significantly easier to use.

Quote:
However, don't the "new" and "delete" commands (and other similar mechanisms) of C++ assume there is some sort of OS to handle memory allocation and that it does it a certain way?


It assumes there is a way for memory to be allocated and freed (malloc/free), but that actually isn't a requirement. You can run C++ on the metal, you just don't get new/delete anymore. New/delete just invoke a C++ function that you can specify.

Quote:
C uses malloc, which is an explicity coded function with an explicitly decided way to manage memory;


It's no more explicit than C++'s new/delete.

Quote:
"The output code will be more suited to the z80 than C or C++" -- Yeah that's a bold claim. I cannot do better than either as far as larger computers are concerned, but on the z80 for a TI-calc ... I retract that C cannot do well on it, I'm sure it could (with a ton of tweaking and all kinds of tools made for it), but my biggest win there is essentially restrictions on the primitive types being only 8 or 16 bits, and the way values are passed (without assuming that an OS provides a heap and using stack frames ... bleh!).


You seem to have forgotten that once upon a time a C int was 16 bit. C was designed for CPUs even more primitive than the Z80. You won't beat C, and you certainly won't beat a mature C compiler like GCC.

Quote:
I know C can pass directly to registers if needed and perhaps NOT use a stack frame to save values in recursive instances, but that requires the programming to know all about that and do it explicitly


No it doesn't. You can pick how to pass the arguments as a compiler-specific keyword on the function. Modern compilers will also automatically inline functions and do other cool optimization tricks.

For example, for GCC you can do this:

Code:
extern void foo(int x, int y) __attribute__((fastcall));


and for MSFT VC++ you can do this:

Code:
extern void __fastcall foo(int x, int y);


and x and y will be passed as registers
Ok, I've experimented with it a lot, and gone through many changes. ...and yes, the "interpreted" stuff tried to kill me Razz

Anyway, THIS is basically the complete documentation as it stands (all previous was very hypothetical), and it's just a TINY bit away from being able to be coded:

http://tinyurl.com/z80opia

Please give it a look and comment! Thanks
I have some questions/comments:

1. If I do this:

Code:
 Foo f= new Foo();

Is f a Foo, or a reference to a Foo?

2. Please no multiple-inheritance. (I cite the DDD)

3. Is it pass by reference or pass by value?

4. Can you make the compiler do the dirty work with pointers?

5. How does a uword/byte differ from a word/byte?

6. I'd be willing to code some of the libraries.
1. Probably the same as in C++/Java.

2. I agree. Though I don't know what triple D's are, just double D's. What is the DDD?

5. U usually denotes unsigned.
DDD= Deadly Diamond of Death:

Class Player{play()}
Class CDPlayer Extends Player{play()}
Class DVDPlayer Extends Player{play()}
Class ComboPlayer Extends CDPlayer, DVDPlayer {}

Which play() does ComboPlayer use?

Picture:
This code:

Code:
 Foo f= new Foo();

is not valid C++ (you would need to insert a star between Foo and f to make f a pointer to a Foo object). In that case, f is a "reference" to a Foo, just as in Java.

Kllrnohj: on some platforms, int still is 16 bits in C. I'm thinking mostly embedded 8- and 16-bit systems, but those kind of systems are pretty common even today. A properly-written C program doesn't assume that int is any bigger than 16 bits, and if it has to use/store numbers larger than 32767 or smaller than -32768 (or if there's any chance for overflow in calculations), it needs to use the long type, which is always at least 32 bits wide.
christop wrote:
This code:

Code:
 Foo f= new Foo();

is not valid C++ (you would need to insert a star between Foo and f to make f a pointer to a Foo object). In that case, f is a "reference" to a Foo, just as in Java.


That is valid Java, not C++.
The interesting thing is that you can be a bit dirty:

Foo f = Foo(); // No "new"; just allocate one statically in the program, construct it, and point to it.
Foo f = static Foo(); // Same, but don't even CALL the constructor; the allocation is basically hard coded in as IF it were constructed this way.

This kind of thing is done all the time in assembly.

...random point, I realize that the Ptr<> wrapper does not allow you to point to other primitive variables (unless I add in the address operator & ); but is that so bad? I mean, is it really good practice to be doing in the first place? Reference-types can still share a reference though; so two Ptr<T>'s can point to the same thing.

...and one thing I left out was the "var" type. It's just a shorthand that tells the compiler to infer the type from the expression, but then it becomes a STATIC type:

var f = new SomethingHugeAndUglyToTypeTwice(...); // f is a .... that

... but using "var" in an inline/interpreted function allows it to re-infer the type per use, so that's kind of a plus Smile
seana11 wrote:
christop wrote:
This code:

Code:
 Foo f= new Foo();

is not valid C++ (you would need to insert a star between Foo and f to make f a pointer to a Foo object). In that case, f is a "reference" to a Foo, just as in Java.


That is valid Java, not C++.

You're right. I was pointing it out to Ashbad since he said it would "probably [be] the same as in C++/Java". I wanted (but failed) to point out that C++ can also allocate f as a Foo, which Java cannot do (variables are only references to objects).

By the way, C++ has one major flaw (IMHO) in this respect. Since you can allocate an object on the stack, the compiled code has to know how big the object is at compile time (eg, so it can calculate offsets to other variables on the stack). This means that whenever you change a class, even just the private members (ie, implementation details), you have to recompile all other code that uses that class. With Java, an object variable is really a reference, which has a fixed size, so there's no need to recompile other classes when one class changes. (I suppose the same would be true in C++ too if all classes were allocated with "new" rather than directly instantiated).
Just to be clear, whether you use "new Foo()", "Foo()", or "static Foo()" does not determine whether or not you have a reference; it just determines how to get/make what you are referencing. Now if "Foo" was a struct, you just don't have the "new" option; but it does not construct until you assign it (a mix of concepts there). You can think of if as that the only thing that ever gets constructed is new or static instances which either get referenced or copied over. However, in the case of structs, I found it totally wasteful to construct into a static instance just to copy it over, so behind the scenes it will actually just (re)construct right into the target struct instance. ... If the compiler finds that it's just a bunch of 1 to 1 assignments tho, it might go ahead and put the values statically into the program and use the z80's array-copy mechanism instead

There is no stack allocation in OPIA; it's 100% static allocations (...yes, I know...); but I figured that was better for a smaller machine, so it's not throwing up overhead for simple things.

The sizing thing was an issue in how I decided to do Generics, though. Read about that topic in that file I linked, if you like. My solutions was to allow there to be different sizes of a single generic thing, but to treat each possible size as a different thing altogether (except where it ends up not mattering).
I'm not too familiar with C, I'm NOT going to learn, so don't pester me, but what is statically allocating something? Is it like a prereq for calling a static method in c?

***EDIT***

What is your plan on packages? eg. how do you plan to implement that? How about a native interface? Will that be in C? Asm?
  
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
» Goto page 1, 2, 3 ... 20, 21, 22  Next
» View previous topic :: View next topic  
Page 1 of 22
» All times are UTC - 5 Hours
 
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

 

Advertisement