LightFusion™

I don't know much about BSTR's because I havn't gotten very far in the ASM tutorial I am reading. Could someone elaborate on them for me. What other types of strings are there?

Quote:

---

Originally Posted by eyeRmonkey

I think I am going to take over the job of documenting the library (similar to how Jake is going to document the syntax). But first we need to decide how the format will be. I would like everyone to suggest ideas on how we should go about this. Sort alphabetically? Sort by data type? In .doc? What fields should we include? Here is all I can think of off the top of my head:

Code:

---

Name:
Type: [Function/Sub]
Parameters: [ByVal/ByRef] [Name] [Data Type]
Return Value: [Data Type]
Description: [Including a short description of each parameter and return value]

---

Please feel free to add to this because I am sure I am forgetting something.

I also think we should get a lot of work done on the syntax now while we don't have many other things distracting us (compiler, syntax, IDE, options, features, etc.). We can discuss how to optimize each library function here and impliment the one we all decide is the fastest.

---

I am quoting this to bring it up again and get more input so I can start documenting stuff and not have to do the work twice if someone thinks up something else to add.

Alphabetically. I also think the documentation should be in HTML format with a treeview style selection. Kinda like the online MSDN.

chem

Quote:

---

Originally Posted by chemicalNova

Alphabetically. I also think the documentation should be in HTML format with a treeview style selection. Kinda like the online MSDN.

chem

---

That sound great but I need an easy way to do it. I can't just write all the HTML myself. I can't even take the time to write some ASP or JavaScript to do most of the work for me. I need a free program that would do it.

Word files are a good option. You can create bookmarks, and an Index automatically

I'm excited.

I just found a file I downloaded a long time ago called HTML Help Workshop. It is by microsoft and its free. It makes .chm (Compiled Help Mechanism) and lets you do everything in HTML (or text). This will be perfect if ever try to deploy the language.

Jake, you should still make a .doc with the syntax, I will just convert it to the .chm as we go.

Quote:

---

Originally Posted by eyeRmonkey

I don't know much about BSTR's because I havn't gotten very far in the ASM tutorial I am reading. Could someone elaborate on them for me. What other types of strings are there?

---

Joacim Andersson explains BSTRs :)

The docs have got a loooooong way to go before I upload it. I gotta cover as much as I can.

And also, for those of you who should know, it cannot look too much like C++, like Java, C#, or any other C++ looking syntax language did. I know it would be easy for people who program in them to port over if it were to have a familiar syntax, but come on. The point in this language is to have easy to read, easy to code syntax, with it running at high speed. And it won't be hard to learn either. Any new language you start programming in, you have to learn eventually anyways, only in this case, it should be cake. The rules however will stay the same. Operators will be the same as C++, stuctures will be structures and not Types, and many other things.

I understand what you are saying Jake because you have mentioned it a few times. Just please keep this in mind as we go: You can't just change it for the sake of changing it.

I realize you want to have this language be its own thing and not like a Cish language, but you need reasons for changing things. An example of a good reason for doing something is how you said you wanted to remove ; because it means less typing. That is a great reason. I don't necisarrily agree with it, but it is a good reason none the less.

On the other hand, changing all the operators for the sake of being different isn't a very good reason.

Back to the use of ";". Since you are doing most of the compiler work, it is somewhat you choice, but as someone (penagate?) mentioned earlier, it is easier for the compiler to look for ; and not CrLF, but that would mean we would FORCE a ; onto the programmer, otherwise the compiler would have to look for CrLF anyway.

So in the long run I agree with you that it shouldn't be in the syntax, but I think it does increase readablity and it makes it easier to do mutiline statements on 1 line.

Quote:

---

Originally Posted by Jacob Roman

The docs have got a loooooong way to go before I upload it. I gotta cover as much as I can.

---

But are you willing to help me transfer you .doc's into this .chm help file? I assuming you know some HTML?

The docs are gonna more be like blue prints of the syntax. Ideas and such.

And I wanted to only change 2 operators. ^ for exponents rather than use it as an XOR operator, and vise versa for something else. But since people have been complaining....

I thought ^ was for exponents? Did I see that discussion in this thread or some thread in Classic VB?

That's what I mean. Let's use that operator for exponents in LightFusion. In C++ ^ was used for the XOR operator. But I couldn't come up with a decent symbol for exponents other than ^. You wanted a reason for certain changes like this one, right?

Yeah, thats a fine thing to change. I don't remember that being brought up in this thread, but I forget a lot of things. I totally agree with that. ^ is exponent in VB right?

What should we do for XOR?

I had a few symbols in mind: @, #, ><, etc. Hmmmm....

why not just make XOR a special one

like perhaps you could have some of the less common operators refered to as their name

vb6 has "Mod" as an operator

perhaps you could have something like #XOR or #XOR#
so you could have others in the same syntax

#XOR
#MOD
#NOT
#IS

Or how about just XOR without the #'s. Easier to read, and less typing.

Sounds like a secent idea to me. Especially because XOR isn't all that common and doing exponents is.

I don't mind #XOR. We could even do that with all our bitwise ones. I don't mind differing from C++ operators in that area. Does anyone have a list of C++ operaters they can link me to? Or should I just reference that C# one we used earlier?

PS - How do you do exponents in C++?

Quote:

---

Originally Posted by Jacob Roman

The docs are gonna more be like blue prints of the syntax. Ideas and such.

---

If its just going to be ideas and such then I will document it later in greater depth.

You include the math.h header and use exp(a,b);

Not good in my opinion. Exponents are more common then they think. You can use the C# link. It's all the same as C++.

Quote:

---

Originally Posted by Jacob Roman

Or how about just XOR without the #'s. Easier to read, and less typing.

---

That sounds good.

pretty sure you can only do exponents in c++ using functions in the math class

Yeah, we definitly need ^ as an exponent operator. And XOR is fine by me for XOR.

XOR in LF is the new mod of VB -- A random text operator.

Since no-one else cares about strings I'll just assume we are using wide char buffers then :)

Pointers can come later. They don't matter to the string routines. And I'll also assume we store the length before the buffer like in VB, and have a terminating null char (for inter-language compatibility).

Quote:

---

Originally Posted by penagate

Since no-one else cares about strings I'll just assume we are using wide char buffers then :)

Pointers can come later. They don't matter to the string routines. And I'll also assume we store the length before the buffer like in VB, and have a terminating null char (for inter-language compatibility).

---

Because noone knows what you meant :p

At least if you have null terminated strings MASM can interface with it :D

As I suggested, but noone expanded on, why not borrow some syntax from Borland stuff? Why go Micro$oft? Pascal, Delphi, etc.

chem

I'm going to quote two sections from The Design and Evolution of C++.

The first is regarding the exponentiation operator, and why there is none in C++. More exactly, it's a list of the reasons that were given when rejecting it. Emphasis in bold is mine, in italics is original.

Quote:

---

Originally Posted by Bjarne Stroustrup

• An operator provides notational convenience, but does not provide any new functionality. Members of the working group, representing heavy users of scientific/engineering computation, indicated that the operator syntax provides minor syntactic convenience.
• Every user of C++ must learn this new feature.
• Users have stressed the importance of substituting their own specialized exponentiation functions for the system default, which would not be possible with an intrinsic operator.
• The proposal is not sufficiently well motivated. In particular, by looking at one 30,000 line Fortran program one cannot conclude that the operator would be widely used in C++.
• The proposal requires adding a new operator and adding another precedence level, thus increasing the complexity of the language.

This brief statement somewhat understates the depth of the discussion. For example, several committee members reviewed significant bodies of corporate code for use of exponentiation and didn't find the usage as critical as is sometimes asserted. Another key observation was that the majority of occurrences of ** in the Fortran code examined were of the form a**n where n was a a small integer literal; writing a*a and a*a*a seemed viable alternatives in most cases.

---

In particular, this means that eyeRmonkey's assertion about the usage of exponents is wrong.
I should also add that game developers, which you seem to be targetting primarily (aren't you?), avoid exponentiation like the pest - nearly as much as square root. The reason is simply that it's slow. The only exponentiations that are interesting are squaring (for distance calculations) and sometimes cubing - and a*a or a*a*a are considerably faster than invoking any sort of subroutine for that.


The second thing I'm quoting are the design principles of C++. I think you should create similar principles for your language, also known as a Whatis-paper.

Quote:

---

Originally Posted by Bjarne Stroustrup

Aims:
C++ makes programming more enjoyable for serious programmers.
C++ is a general-purpose programming language that
- is a better C
- supports data abstraction
- supports object-oriented programming

General rules:
C++'s evolution must be driven by real problems.
Don't get involved in a sterile quest for perfection.
C++ must be useful now.
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
C++ is a language, not a complete system.
Provide comprehensive support for each supported style.
Don't try to force people.

Design support rules:
Support sound design notions.
Provide facilities for program organization.
Say what you mean.
All features must be affordable.
It is more important to allow a useful feature than to prevent every misuse.
Support composition of software from separately developed parts.

Language-technical rules:
No implicit violations of the static type system.
Provide as good support for user-defined types as for built-in types.
Locality is good.
Avoid order dependencies.
If in doubt, pick the variant of a feature that is easiest to teach.
Syntax matters (often in perverse ways).

Low-leel programming support rules:
Use traditional (dumb) linkers.
No gratuitous incompatibilities with C.
Leave no room for a lower-level language below C++ (except assembler).
What you don't use, you don't pay for (zero-overhead rule).
If in doubt, provide means for manual control.

---

These may sound rather cryptic. Stroustrup goes on to explain every one in detail, but obviously I won't copy that.
I don't expect you to follow these rules. After all, if you did, you would be re-developing C++.

However, I think it would be a very good idea for you to make rules of this kind for your own language. Start with the first list and work your way down.

Unless you do that, your entire effort is pure chaos and thus doomed. Just look at you: you haven't yet decided what design and code organization features your language supports, yet you're already designing its library. What if you later come up with a really good feature that you want to use in the library? Will you just throw it all away? Or will you not use the feature, thus making the library harder to use than necessary?

Quote:

---

Originally Posted by CornedBee

I should also add that game developers, which you seem to be targetting primarily (aren't you?), avoid exponentiation like the pest - nearly as much as square root. The reason is simply that it's slow. The only exponentiations that are interesting are squaring (for distance calculations) and sometimes cubing - and a*a or a*a*a are considerably faster than invoking any sort of subroutine for that.

---

Well that is why we are gonna come up with faster methods of square rooting, and exponentation, plus many other math functions. NoteMe has a fast sqrt() one that I like a lot.

Code:

---


inline float Sqr(float x) { 

    float y; 

    _asm { 
      mov ecx, x 
      and ecx, 0x7f800000 
      fld x
      mov eax, ecx
      add ecx, 0x3f800000 
      or ecx, 0x00800000 
      shr ecx, 1 
      mov y, eax 
      and ecx, 0x3f800000 
      fld y
      fadd
      fstp y 
      and [y], 0x007fffff 
      or [y], ecx 
    } 
return y;
}

---

People have always been coming up with faster square rooting methods for their 3D engines using inline assembly, and it ended up computing a whole lot faster than the typical sqrt() function.

I suggest that we provide operators for opcodes that exist in assembly (such as AND, NOT, OR, XOR, ADD, SUB, MUL, etc.) and leave the rest for library functions. We can optimise our functions so we get them fastest we can, but leave it so people are free to use their own instead. What do you think Jacob.

I'm afraid I'll have to call bull on this square root method. It totally doesn't work.

First column is the assembly method, second is the math library version.

Code:

---

sqrt(2) = 1 / 1.41421
sqrt(3) = 1.25 / 1.73205
sqrt(4) = 0 / 2
sqrt(5) = 1.46937e-039 / 2.23607

---

I even booted into Windows and copied & pasted into VC++.Net 2003, just to prove that I didn't make any mistakes while translating to GCC assembly syntax. (I didn't, and GCC rules, btw.)

Also, game programmers are not so much looking for fast square rooters as they're trying to avoid square roots altogether.

Just for fun, some profiling. I took the faulty assembly routine, the standard math library square root, and my own routine:

Code:

---

inline float directsqrt(float x)
{
        float y;
        _asm {
                fld x
                fsqrt
                fstp y
        }
        return y;
}

---

I executed each one 100,000 times to calculate the square root of 2, timing the thing with the Windows performance counter (most precise timer available.) The timings are as follows:

Code:

---

Math library... 29227 ticks elapsed.
Faulty asm... 16985 ticks elapsed.
Sqrt asm... 17940 ticks elapsed.

---

I believe, however, that the considerably larger value for the first version is mostly function overhead.

Thus, your so-called better routine has, leaving aside that it doesn't work, a mere 5.4% speed increase over the CPU sqrt instruction.
Oh, and even that might be offset by the fact that mine uses only the floating point part of the CPU, and thus the integer part is free to do other things. Especially relevant in hyperthreading.

The "faulty" Sqrt function you have there is an aproximation of Newton Raphsons method. It was used in Quake 3.



- ØØ -

I don't believe that for a second. Somewhere between Quake 3 and this forum must be a significant error. I doubt Q3 would work properly with a routine that claims that 0 is the square root of 4.

You are totaly right...NO idea what is wrong. I just searched for it on the internet, and pasted it, because I know it is out there..didn't bother to test it..:)


Here is an other one..:)

Quote:

---

inline float rsqrtf(float v){
float v_half = v * 0.5f;
long i = *(long *) &amp;v;
i = 0x5f3759df - (i >> 1);
v = *(float *) &amp;i;
return v * (1.5f - v_half * v * v);
}

---

PS: Inverse sqrt.

or:

Code:

---


inline float fsqrt(float x)
{
    __asm
    {
        rsqrtss xmm0, x
        rcpss xmm0, xmm0
        movss x, xmm0
    }

    return x;
}

---

Or:

Code:

---

inline float fsqrt(float x)
{
    static int big = 7F7FFFFFh;

    __asm
    {
        rsqrtss xmm0, x
        minss xmm0, [big]
        mulss xmm0, x
        movss x, xmm0
    }

    return x;
}

---

done now..:)

Wonder if the SSE will give it any boost. Might bench those myself :)

Sounds better. Still, if you want fast math, no need to create a new language for it.

Quote:

---

Originally Posted by penagate

Wonder if the SSE will give it any boost. Might bench those myself :)

---

Try SSE2.

Here's an idea for the language: make it inherently support SIMD/Vector math, that is, provide facilities that lead the programmer to write code that can be compiled to SSE/3dNow!/Altivec instructions.

Quote:

---

Originally Posted by NoteMe

Try SSE2.

---

- It looks like SSE;

- I have an Athlon XP so if it was SSE2 it wouldn't run ...

YOu have vector compilers for C++ too though. A really fast one is VectorC:

http://www.codeplay.com/vectorc/



- ØØ -

I'm talking about language features that encourage writing code in a way that is easy to optimize, though. A bit like the valarray class of C++.

Quote:

---

Originally Posted by CornedBee

Here's an idea for the language: make it inherently support SIMD/Vector math, that is, provide facilities that lead the programmer to write code that can be compiled to SSE/3dNow!/Altivec instructions.

---

I know the Pentium 4 processors involve SIMD instructions, but what about AMD/AMD 64's?

Athlon XP's don't support SSE2. Other than that they support the same instruction set as the P4. Older processors, I'm not so sure about. That is where you need processor-specific compiler optimisations. But if the language encourages writing code that compiles to newer instruction sets then it doesn't preclude compiling that code to older instruction sets, it will just be a lot slower (without the processor optimisations).

Athlon XP support SSE, Athlon 64 SSE2, and the newest 64s even SSE3.

So we should use the SIMD instruction set then, right? Since it is supported for the latest processors. SSE and SSE2 I'm not not sure is used on Pentium 4's, which is why I'm thinking of using SIMD.

SIMD (Single Instruction, Multiple Data) is just a design technique. SSE (Streaming SIMD Extensions) 1, 2 and 3 are the actual instructions sets using this technique.

Oh I didn't know that. I also heard that the Playstation2 uses SIMD as well. So what should we use, SSE1, 2, or 3? I think 1 is good for now.

You use whatever is appropriate, and provide alterante code paths for CPUs that don't support it.

Hmmmmm. Good idea. That way there we can take advantage of the latest processors.

So what is SIMD/SEE? Is it an ASM instruction set?

CornedBee, thanks once again for all your expertise. I really apriciate it. What is GCC? An ASM compiler or a C compiler? Is it free? We will probably stick w/ MASM or whatever is in Jake's book, but I would like to look into it?

Quote:

---

Originally Posted by Penagate

I suggest that we provide operators for opcodes that exist in assembly (such as AND, NOT, OR, XOR, ADD, SUB, MUL, etc.) and leave the rest for library functions. We can optimise our functions so we get them fastest we can, but leave it so people are free to use their own instead. What do you think Jacob.

---

I like the idea of only providing operators for those things and making functions for the rest. I think that might allow for the most optimization, but I could be wrong.

I agree with CornedBee about the ^ operator. It makes sense to me. What do you think Jake? Penagate? Chem?

I also agree about writing a list of rules to focus on. I think the essential.

Same here. I'm not a hardcore game programmer, but I find I don't have much use for ^ either. Except when drawing circles..

chem

Even for circles you could do r * r easily.

PS - CornedBee, you mentioned the focus of LF being game programmers. I think that might be one of the areas we try to focus on (because Jake is big on it), but I don't think that is what we want our langauge to be known for (but I don't know what we want our language to be known for).

SSE1, 2, and 3, which is all a part of SIMD (Single Instruction Multiple Data) are instruction sets built into the latest processors. It's even used in the Playstation 2. I'm not sure which ones are assosiated with what, but what I do know that SSE is in the Pentium 4 and AMD processors, and SSE3 is in the AMD 64. Yes it is assembly, and can still be done in C++. But it executes faster than the regular X86 instruction set. It's a good way to take advantage of the latest processors out there. We are looking for speed, right?

I know this isn't related to assembly, but I haven't actually decided on what to do for the operators just yet. I'm conteplating whether I should use commands as the bitwise operators (like VB did), or symbols. Commands allow better code readability, while the symbols can allow the bitwise operators to be the same as C++, and less typing. And I know those C++ gurus are gonna want the C++ style operators.

Now as for assembly, we will support as many types of assembly as we can for the assembly tags, such as the x86, SSE1, 2 and 3, and any others that we can think of.

While I was at work today, a million and one ideas popped into my head on what I should do for this program. For example, I'm not sure if this is possible, but after writting a compiler, should I also write a decompiler? It would be a breach of copyrighted code for programs written in LightFusion, but I think the decompiler should be left to us and not exactly come with the package. It's a thought though.

Then some thoughts occured to me about the exes themselves. I think it would be nice to make it a stand alone exe that doesn't require any framework or external dlls to run it.

I started these threads to help us get an idea of what we should change about LightFusion from other languages.

VB6: http://www.vbforums.com/showthread.php?t=360315
VB.NET: http://www.vbforums.com/showthread.php?t=360316
C#: http://www.vbforums.com/showthread.php?t=360319
C++: http://www.vbforums.com/showthread.php?t=360321

Quote:

---

Originally Posted by Jacob Roman

SSE1, 2, and 3, which is all a part of SIMD (Single Instruction Multiple Data) are instruction sets built into the latest processors. It's even used in the Playstation 2. I'm not sure which ones are assosiated with what, but what I do know that SSE is in the Pentium 4 and AMD processors, and SSE3 is in the AMD 64. Yes it is assembly, and can still be done in C++. But it executes faster than the regular X86 instruction set. It's a good way to take advantage of the latest processors out there. We are looking for speed, right?

---

Thanks.

Quote:

---

Originally Posted by Jacob Roman

I know this isn't related to assembly, but I haven't actually decided on what to do for the operators just yet. I'm conteplating whether I should use commands as the bitwise operators (like VB did), or symbols. Commands allow better code readability, while the symbols can allow the bitwise operators to be the same as C++, and less typing. And I know those C++ gurus are gonna want the C++ style operators.

---

I think using commands for bitwise operators would work fine. It is how you see them commonly written in other places. I think they should be in caps also not And like and in VB, but AND and NOT, etc.

Quote:

---

Originally Posted by Jacob Roman

While I was at work today, a million and one ideas popped into my head on what I should do for this program. For example, I'm not sure if this is possible, but after writting a compiler, should I also write a decompiler? It would be a breach of copyrighted code for programs written in LightFusion, but I think the decompiler should be left to us and not exactly come with the package. It's a thought though.

---

decompiler is way down the road, but it is something I think about from time to time and a good idea if it is possible. Lets focus on what CornedBee said about making a list of rules for the programming language. How aboue we make a goal to have that done (or mostly done) by the end of the week?

Quote:

---

Originally Posted by Jacob Roman

Then some thoughts occured to me about the exes themselves. I think it would be nice to make it a stand alone exe that doesn't require any framework or external dlls to run it.

---

I disagree. DLLs are nice because you can get the most updated version easily. I definitley think we need good options that allow LF to interface w/ .DLLs and .OCXs.

I think its a lot better idea to offer a good Package & Deployment Wizard than to try to restructure the use of .DLLs and what not.

If I do stick with commands for bitwise operators, then we got ourselves an exponent operator. The only difference between VB and LF, is that LF will be way faster when it comes to exponents. :thumb:

I think you missed an important point CornedBee made. If you add exponents and/or square roots then you add anothe presedence (sp?) level as in exponents have to be computed before * or / and those have to be computed before + and -. If you leave exponents to a function then you don't have to do as much compiler work (and I bet adding each presedence level means a lot more work). I think you should leave it as a function.

Presidence :D

chem