I already knew that for a long time, CornedBee. It's faster cause it operates on multiple data at once. Hence the term SIMD (Single Instruction Multiple Data). I haven't mistaken at all on that. ;)Quote:
Originally Posted by CornedBee
Printable View
I already knew that for a long time, CornedBee. It's faster cause it operates on multiple data at once. Hence the term SIMD (Single Instruction Multiple Data). I haven't mistaken at all on that. ;)Quote:
Originally Posted by CornedBee
And I insist that you are strongly mistaken on that. The instances where SSE gives you a major speed boost are rare.Quote:
so there can be a major speed boost.
That doesn't even take into account that modern compilers (GCC, VC++) DO output SIMD instructions when they deem it the right thing to do, and when you allow them to. They won't if you're asking them to generate generic i586 code, because such stuff wouldn't run on the Pentium. However, if you give GCC the -march=pentium4 flag, it will happily generate code that uses SSE 1, 2 and 3. If you give it -march=athlonxp, it will use 3dNow, 3dNowExt, SSE 1 and perhaps 2 (not sure if the XP supports it). And so on.
Athlon XPs only support SSE 1. Athlon 64's support SSE 2.
Actually penagate, It's Athlon 64's that supports SSE3 and AMD Athlon that supports SSE2. Anything from Pentium 3 and above supports SSE 1 ;)
And Cornedbee, it's the fact that it works with multiple data that gives it that speed boost. And it supports many instructions that x86 doesn't have. If the SSE were working with only one instruction at a time like x86, then yes they are the same speed. So you were mistaken on the fact that I mistaken. If anything you misunderstood me. ;)
[EDITED ABOVE]
Are you incapable of using Google.
http://en.wikipedia.org/wiki/SSE2
http://forums.amd.com/index.php?show...0&#entry520915
I repeat, the Athlon XP does not support SSE2.
SSE was introduced with the Pentium III, and AMD added support with the Athlon XP.
http://en.wikipedia.org/wiki/Sse
Know your facts, before posting such an authoritive statement.
Yeah your right, it did start from Pentium 3.
Perhaps I misunderstood it. You claimed that using SSE would give it a speed boost. But relative to what? To standard i586 instructions? Yes, in some cases, but that's nothing spectacular. So I assumed you meant relative to existing languages/compilers; that was a good guess based on the context of the debate. And there you are wrong, because you won't gain a speed advantage in that case.Quote:
Originally Posted by Jacob Roman
Okay we have a few things to clear up:
Girvo: If you don't feel you have the time to work on this project then now is the time to say so, but beyond you leaving the project, we want you here and are VERY happy to have you. You being 14 has nothing to d with anything as long as you are dedicated to this. I am only 17 so don't feel bad. I'm impressed that you have done what you have at that age. I still don't know C, but I think (after learning VB) that if I tried to learn it again (for the 3rd time) I would do fine, because I understand a lot of the concepts that I couldn't understand about C/C++ (pointers being one). But enough about me...
What Jake said about his work with compilers has nothing (directly) to do with LightFusion. As far as making a compiler, we won't be making it from scatch. All we will be doing is parsing LF into C. The only jobs you have to do is parse the LF code, translate it into C, and make the code as efficient as possible. My only question for you is: Do you have the time/desire to do this?
Penagate: I like the idea of converting global variables to properties. As long as we allow the user to access the get/set methods IF they need to, we should be fine. CornedBee, what was your counter-argument to this?
Char/Byte discussion: You are right Penagate, I didn't catch the part about how "Char" can be 1 or 2 bytes depending on wether its compiled into Unicode or not (BTW - there is just a little irony in the fact that UNIcode has TWO bytes and ANSI only has one).
So that leads me back to my original question. How do we implement a Byte data type without having a Byte type to work with in C?
SEE/Jake's Compiler: Not to be rude, but we are done with this. It's not relevant to what we are working on and what we are trying to focus on. If anyone wants to continue this discussion please do it through PMs.
Semicolon/Parenthesis Argument: I think I am making an exectiuve decision on this one. Semicolons are in. I will make the IDE write them for you most of the time which nullifies Jake's argument about them being hard to type.
Parenthesis are easy to type and I see it as being a worthwhile readability increase, so I think they are in as well. I know you don't want this language to look like C Jake, but we don't have Ph.Ds (like the people who made C and there is no reason to change things for the sake of changing things. If you can make a different argument to have them removed then I will consider it. I want to move on with developing the syntax.
Back to syntax development: Jake, do you have any more of the syntax ready? If not then how long will it be until it is ready? I hope it won't be long.
NOTE - All questions are italicized. Please answer them if they involve you.
I see how it is. With me lagging behind not having a computer and all, you force semicolons and parenthesis into the syntax and make that decision final?!!! I made it optional for a reason, eyeR.
And CornedBee doesn't realize how fast SSE instructions really are. It makes a big difference when using them, plus it has instructions that x86 doesnt have. This would be a great opertunity to take advantage of the latest processors.
Well what was the reason, was I think eyeRmonkey's point.
Jacob, I'm sorry, I didn't mean to make you mad. Can we try to be mature about this? Or am I misinturpreting your '?!!!' ? I think we need to move on with the syntax. There are more important things than parenthesis and semicolons. As far as I see it, the advtanages of including semicolons outweigh the disadvantages. If you can prove otherwise then be my guest. If you are just doing it because you "don't want it to look like C" then thats just not good enough.
Can we please be done with the SSE stuff? I want to keep the ball rolling on this project and that is unrelated. PM CornedBee if you want to keep talking about it.
That it went against your own principles, in particular the language making it obvious what the compiler is doing.Quote:
CornedBee, what was your counter-argument to this?
Then again, I'm personally an opponent of properties for that very reason.
CornedBee, I think we can do it the way penagate suggested (if we choose to) by disallowing global variables period, then, when the user adds what would be a public variable, putting a +/- box next to it and minimizing it. That way the let/get stuff is still there, and the user still knows how it is working, but now they have to use properties.
The other point on which it goes against our principles is that we are forcing the programmer to do it a certain way. As far as this is concerned, I think we are forcing them a lot by doing this. Of there are advantages to it, but I we are taking away too much control from the programmer.
I think we can compromise like this:
* Make it easy for the programmer to change a public member into a property (using the IDE)
* Make the +/- box next to the property minimized by default so the user doesn't have to think about it as much.
* Promote the use of properties over public variables in other ways (tutorials, help files).
What do you guys think about that?
I think you're going to have a hard time creating these "Regions" with the +/- stuff in the IDE.
Seriously, I think flexibility is what you need. None of this forcing stuff crap.
Honestly, the way you are all talking, is turning this language from "Beginner Friendly", into something like C. I'm not saying thats bad, but this alone is going against one of your guidelines isn't it? Do "Beginner Friendly" languages have 400,000 sizes of and Integer? Also, if you want it nothing like C/C++, then this too is changing it from "Beginner Friendly", to something which would need to be researched, in order to find out how it all works.
In closing, I guess I agree with CornedBee.
chem
I think that it simply shows that, after all this time, you still do not understand the difference between a language, a compiler, and an IDE, and this ridiculous squabbling over irrelevant syntatic details shows that this project still has no clearly defined purpose. The forced property suggestion was made because I was under the impression that this was supposed to be a language that was easy to learn and understand. You can't have infinite power, simplicity, and absolute ease of use. A trade-off must be made and I find it astounding that the compromises have not yet been clearly defined, when already there is discussion of compilers and syntax (which contrary to the prevalent belief in this thread, does NOT define a language).Quote:
Originally Posted by eyeRmonkey
Anyway, you can consider me no longer a part of this project. Good luck :wave:
Penagate, I'm sorry to hear that you are leaving us. I really hope you aren't leaving a bad note and that you will still poke you head around here every now and then (if we last any longer).
I do understand the difference between a compiler/IDE/language (but only because of my work on this project). In this case the IDE would simply assist in the code writing process instead of forcing the programmer to use properties. If they typed code outside the IDE then they would have to type the get/set methods themselves.
I have been attempting to make comprimises all along although, I may have been trying to have the best of every world too often. You're right the level of importance of all the rules should have been defined so we can decide what trade-offs need to be made.
I know syntax isn't all that defines a language. But it is big part. Pre-planning and a defined goal would have helped this project a lot. That seems to be one of our biggest weaknesses. But none of us have ever done this before. I admit I am guilty of wanting to do the fun parts (writing the code and skipping straight into the syntax) and not getting down to business about clearly defining the language and where we want to head with it.
Seeing Penagate's and chem's replies next to each other made me realize something that I hadn't thought of directly before. One of our rules was ease of use. Chem mentioned ease of use by staying close to C syntax so the user doesn't have to research the language. Penagate mentioned doing innovative things make it easier to learn than current languages, which makes the user have to research/learn the language.
I see doing innovative things as being better, otherwise we are just a C clone with users who could just as easily use VC++ or any other C compiler (and most likely will). We have to be better in the area of innovation. I think that is an important item to note and should be added to our rules list. The addition would read something like this: When in doubt, favor innovation over other rules.
Do you guys agree with that? Or do you think we should be more like C and make easier to learn?
Hey there.
I saw you post this eyeR:
Well'p, I'm sorry to say but it might be true. I don't know whether I can do what you are asking for this compiler.Quote:
Originally Posted by eyeRmonkey
One of the main problems with this project is you attempted too much, too soon. You should have started with a SMALLER and EISIER project. Anyways, I'm no longer part of this project. THanks for the experince though, and I expect to have learnt from your mistakes. Anyways, I am starting up my project fully now, ModBASIC, and I'm gonna need someone to help with the IDE so....
Anyways, Thanks!
-Girvo
eyeR, throughout this thread there have been many things that have upset me. No matter how innovative I was, I was told "no its a bad idea." I wanted SSE assembly outputed, Cornedbee kept on telling me "no it doesn't matter. it'll be the same speed as x86, there wont be much speed difference." But I keep telling him the speed that it'll get is when it works with multiple data at once. Then on the syntax, no matter what I suggest or do, you guys practically say "no no it's gotta be like this and this...." and next thing you know, we practically have C++ as the syntax again as the result! Every language is different, and yes when it comes to different languages, of course you gotta learn it. It doesn't mean that every new language that comes out has to look like C++ just to get people to port over. I did not want semicolons because 1) it made the syntax look like a C++ clone 2) it made the syntax look harder to read in my opinion 3) It's less typing not having them 4) It makes it easier on people not having them, especially beginner programmers 5) It's Too Error Prone! C++ tends to be very error prone, especially when it comes to semicolons. 6)It sticks with my rule that I wanted it to be a cross between C++ and VB. This whole time that this whole team was turning it into C++, you forgot that it was suppose to be a blend of both languages, hence the name LightFusion. I don't want to leave this team, but we need to work as a team, so people don't leave on us, and so we can finally get this project going.Quote:
Originally Posted by eyeRmonkey
Well, I'm sorry to say that I think I am done with the project as well (for the time being). I went into this hoping to learn something and I have learned A LOT. I don't want to leave you on bad terms and I'm sorry about the things that have upset you about what we have done.
I really enjoyed making the IDE (even though you guys never got to see it) and I learned a lot about programming in general.
If you do get a compiler actually started sometime in the future let me know I would be more than happy to make the IDE for it, but beyond that I think this project is beyond my abilities at this point. I don't have the time to learn what I need to, to make this project happen.
I had the feeling from the beginning that LightFusion wouldn't see even a "Hello World" app, but I chose to help anyway, because I thought it would be an awesome way for me to learn things about how compilers work and about programming in general, and it has been just that.
I am really disappointed that I can't work on the IDE any more, because I was really proud of what I accomplished. If you guys would like to see the source code or a compiled version of it, drop me a PM, it looks great.
Since I am leaving, I want to be as much help to Jake (and anyone that wants to continue on this project) as possible. I need to transfer admin rights of our source forge account to you Jake and if anyone wants it, I have all the source code for the IDE, a framework of the help documentation, all the graphics, a list of all the research I did for the IDE and a lot of other documentation about the aspects of this language. I also have a detailed list of all the modifications I made to the IDE and all the ideas I had for adding to it (there are some really cool ideas in there).
I never denied that. I merely claimed that the situations where you can take advantage of this are rare, thus the real-world advantage (and you still haven't said above what you want to have the advantage) is minor.Quote:
Cornedbee kept on telling me "no it doesn't matter. it'll be the same speed as x86, there wont be much speed difference." But I keep telling him the speed that it'll get is when it works with multiple data at once.
Jake, if you want the rights to the sourceforge account let me know by this Thrusday, otherwise I am closing the account. Also let me know if you want any of the stuff I listed in post #1019. I won't delete it any time soon, but I won't hold onto it forever either.
Uh... so is this project still active?
You would have to ask Jake. He probably wants to continue it, but at the moment I think he is also the only team member (unless you are still helping out Datacide).
Why not just make wrapper classes that make c++ do what you want. That will save you alot of time and money.
I also like the ; and {} and pretty much everything in c++. If you know how to type, and type properly, you know that your pinky is always on ; anyway.
I did not want LF to be another C++ clone, but a cross between VB and C++, hence the name LightFusion. And I'm working on the project on my own. So it's not a dead project nor is it inactive. Just inactive to the team members who decided to quit.
Jake, do you want to have access to the sourceforge project account or not?
I am deleting it sometime today if you don't want it.
Actually you can delete sourceforge. I plan on getting a site up after much of the project has be complete.
Jacob Roman, do you need any help in the look of your app? i would love to help with its look, that if you need any help... (icons,menu,toolbar,etc..)
Too late. I already made myself an IDE a long time ago. ;)
Sigh...Quote:
Originally Posted by Jacob Roman
No offence, but this is way past your abilities.Quote:
Originally Posted by wiz126
chem
:lol:Quote:
Originally Posted by chemicalNova
Ouch.Quote:
Originally Posted by chemicalNova
Offtopic:
Is Jacob Roman really banned? o.O
LOL again? hehehe
AGAIN!?
Bad times. I'm gonna go search his posts to see what he did recently. :/
No surprise there.... :rolleyes:Quote:
Originally Posted by k1ll3rdr4g0n
EDIT: So it's still going.. EVEN NOW??? :ehh:
On and off, only I haven't worked on it in awhile considering the fact that I have no computer, and have been using my parents computer for making DX tutorials, web browsing, making MKvsSF, and other things.
How far are you guys on this project?
The project is null and void as of many months ago. Sorry. :(
to bad it sounded pretty cool