Omnimaga
Calculator Community => TI Calculators => Lua => Topic started by: Hot_Dog on June 05, 2011, 12:08:12 pm
-
I heard from someone that Lua on the Nspire is darn close to the speed of C/Asm on the Nspire. Do you think the community will use Ndless nonetheless, or do you think hacking the Nspire will be a successful, yet unneeded, effort?
-
I'm quite fine with Lua alone, we've seen some cool and impressive programs made with Lua, I don't think there will be a need for C/Asm anymore.
-
I'm quite fine with Lua alone, we've seen some cool and impressive programs made with Lua, I don't think there will be a need for C/Asm anymore.
I disagree, I'd like a GBC Emulator, I'd like lots of stuff that just can't be made with an interpreted language, I'd like to code in C and perhaps ARM, Ndless is needed.
-
Of course I'm not an Nspire dev. But since Lua is sand boxed, I would compare Lua to this situation.
Imagine that TI-Basic suddenly became as fast as asm. (Yeah right) That would mean that you would be able to write basic games that roughly equal the power of asm games. So as far as the game world goes, no, there would be no need for asm.
But now, try to write a shell in TI-Basic. One that can list all the programs on the calculator and execute them at random. You also want your shell to install a hook that allows programs to be run from the homescreen and setup some more hooks just to make the calculator generally easier to use. (Think zStart). Through TI-Basic alone, you cannot write Utility programs, so you must then fall back on asm even though Basic is crazy fast.
So, assuming that Lua is similar to TI-Basic as far as being sand boxed, my analogy should work.
-
I agree with Scout on this one. Lua is pretty awesome, but it doesn't let us do all that stuff we can do with C/ASM. nDOOM, gbc4nspire, and NESpire would never have been possible in Lua, remember.
-
Agreed. Getting Ndless might cause TI to block that and Lua too.
-
I also have to remind that Lua doesn't allow fullscreen, stuff have to be inside documents, and that's a huge advantage of C and ASM for me.
Agreed. Getting Ndless might cause TI to block that and Lua too.
"Agreed" on what? Please tell us who you are referring to.
-
You have to have C/Asm for this. Eventually we will hack it on.
-
"Hack" as in "void the warranty"? I have nothing against these two programming languages, and many of the games so far wouldn't be possible without Ndless, but I'm just fine with Lua.
-
Ah yes, C/ASM do allow full control
-
"Hack" as in "void the warranty"? I have nothing against these two programming languages, and many of the games so far wouldn't be possible without Ndless, but I'm just fine with Lua.
He means hack as in unlock the calculator to make it run Assembly programs. Do you have any idea of how Lua is limited when compared to C and ARM? That's why most of us think that Assembly is needed.
-
They can't reasonably block Lua now, the backlash (not just from us hobbyists - also teachers who are currently warming up to the possibilities offered by Lua) would be too high ;)
And no, Lua will never ever erase the need for native code :)
Especially if TI's Lua implementation remains purely interpreted: the LuaJIT performance pages ( http://luajit.org/performance_arm.html , http://luajit.org/performance_x86.html ) show that in some use cases, LuaJIT is more than two orders of magnitude (100 times) faster than regular Lua - and code produced by LuaJIT doesn't execute as fast as the equivalent native code would, so the gap between interpreted Lua and native code is even larger.
Besides performance unmatched by Lua, native code enables deeper (near-full) control over the devices we own, rather than being limited to what TI feels like providing - namely, a stripped-down Lua.
[EDIT: I see that several posts have been posted while I was writing mine :) ]
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
But as Lionel Debrouxl said and correctly, they'll never remove Lua. Do you still not want ARM?
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
But as Lionel Debrouxl said and correctly, they'll never remove Lua. Do you still not want ARM?
What's ARM?
Please forgive my noobiness. :P
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
But as Lionel Debrouxl said and correctly, they'll never remove Lua. Do you still not want ARM?
What's ARM?
Please forgive my noobiness. :P
ARM is the name of Assembly (and I'm also including C now) for the NSpire processor.
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
But as Lionel Debrouxl said and correctly, they'll never remove Lua. Do you still not want ARM?
What's ARM?
Please forgive my noobiness. :P
ARM is the name of Assembly (and I'm also including C now) for the NSpire processor.
What can you do with it that Lua can't do?
Although, I have to admit, Lionel has a good point with the teachers getting warm to the possibilities of Lua.
-
pianoman: for some instances of the things Lua can't do, but native code could, see posts by thepenguin77, Deep Thought and Scout, earlier in the topic :)
-
Ah. I see your point.
-
Whoops, it appears i got triple ninja'd. I was agreeing with Spyro.
But as Lionel Debrouxl said and correctly, they'll never remove Lua. Do you still not want ARM?
What's ARM?
Please forgive my noobiness. :P
ARM is the name of Assembly (and I'm also including C now) for the NSpire processor.
What can you do with it that Lua can't do?
Although, I have to admit, Lionel has a good point with the teachers getting warm to the possibilities of Lua.
Speed is a lot less. YOu can not run other programs from it(at least I don'tthink so),
-
- Full Screen Applications
- Total control of the calculator with code
- Much faster
These are just some of them.
-
Short answer: No.
Long answer: NOOOOOOOOOOOOOOO
Real answer: Lua really isn't as fast as C/ASM, and I love to program in ARM assembly. You won't be getting your GBC emulator in real color on the CX without Ndless, or any of the other awesome stuff that could be possible with full control of the hardware (like nDoom for example)
-
I don't mean to prolong the beating of this horse, but I just want to throw in this analogy:
Look at modern computers. Interpreters are bloody fast nowadays, with advanced JIT compilation and other optimization techniques. In some specialized cases, they can even beat compiled code for speed. They're also not limited in their functions, since pretty much anything that can be written in a compiled language can also be done in an interpreted one. However, people still use compiled code for many things. You're not going to write Crysis in Java (Minecraft is already pushing the limits). Some programs are simply too advanced for interpreters and also, sandboxing means that anything that has to interface with the OS in ways that weren't intended has to be compiled or assembled.
-
An interpreter, in most cases, especially if made by TI, will never achieve ASM/C performance on the identical same platform. You will never see nDoom, Ocarina of Time port or even a GB emulator in Lua. In fact, I heard that even smooth scrolling tilemaps were impossible.
-
Huh, I don't know why I thought Lua was pre-compiled--maybe it's because of how much faster it is than Ti-Basic
-
Maybe. A lot of games look ASM-like. THe reason why it's so fast is because the calc uses a CPU over 100 MHz, while on the 83+ you got a 6 MHz one.
-
As stated by others, I highly doubt that Lua will replace the need for C. Although it is a wonderful addition to the Nspire, Lua is still limited in its functions, unlike the endless possibilities of Ndless! :)
-
Short answer: No.
Long answer: NOOOOOOOOOOOOOOO
Real answer: Lua really isn't as fast as C/ASM, and I love to program in ARM assembly. You won't be getting your GBC emulator in real color on the CX without Ndless, or any of the other awesome stuff that could be possible with full control of the hardware (like nDoom for example)
My answer:
NO.
But seriously, Lua is a great language, but it's pretty impossible to compare it to C or Assembly -- they're entirely different and should never be used in the same sentence unless you're embedding Lua code in C or making a C compiler in Lua. Lua is many, many times slower than C; Lua is functional, C is procedural; Lua is interpreted, C is compiled; Lua is usually used for simple scripting, C is usually used for stand-alone applications; C has full access over lower level parts of the OS and the hardware itself; Lua can't do that at all without built-in support or being embedded in, well, something like C. I can go on and on ;)
-
...C has full access over lower level parts of the OS and the hardware itself...
Technical Correction: C has partial access to the lower level parts of the OS and the hardware itself. Some things just can't be done without dipping into inline ASM. C does a heck of the lot, though, to be fair.
-
...C has full access over lower level parts of the OS and the hardware itself...
Technical Correction: C has partial access to the lower level parts of the OS and the hardware itself. Some things just can't be done without dipping into inline ASM. C does a heck of the lot, though, to be fair.
That's true. I guess you can substitute C/ASM for just C there :)
-
"Hack" as in "void the warranty"? I have nothing against these two programming languages, and many of the games so far wouldn't be possible without Ndless, but I'm just fine with Lua.
If you want to continue to enjoy the games that have been produced to run under ndless thus far then ndless is still necessary. As new Oses are released and downgrade protection is added, new versions of ndless are required to operate on the new Oses. I'd imagine the Non-CX Nspires are on their way out, and soon the only calculators capable of even running Ndless will be the old models that haven't upgraded to the new OSes.
Also agreeing that while the addition of LUA is nice, it's no replacement for ASM/C.
-
...C has full access over lower level parts of the OS and the hardware itself...
Technical Correction: C has partial access to the lower level parts of the OS and the hardware itself. Some things just can't be done without dipping into inline ASM. C does a heck of the lot, though, to be fair.
Just to go farther there are some things you can't do in asm either. Take windows for example, you can't get full control of the cpu due to the way the virtual memory is organized. In fact only Windows itself is allowed to view the physical memory. For some things you have to rely on the OS to do some things, which can be both good and bad. In some cases syscalls are very well written plus it prevents programs from corrupting the system. But as we know with TI many syscalls are very poorly written, but we are forced to use them.
-
...C has full access over lower level parts of the OS and the hardware itself...
Technical Correction: C has partial access to the lower level parts of the OS and the hardware itself. Some things just can't be done without dipping into inline ASM. C does a heck of the lot, though, to be fair.
Just to go farther there are some things you can't do in asm either. Take windows for example, you can't get full control of the cpu due to the way the virtual memory is organized. In fact only Windows itself is allowed to view the physical memory. For some things you have to rely on the OS to do some things, which can be both good and bad. In some cases syscalls are very well written plus it prevents programs from corrupting the system. But as we know with TI many syscalls are very poorly written, but we are forced to use them.
Technically we do have full access, because the TI-Nspire OS doesn't implement user/system modes so it's always in system mode. (They had no reason for a user mode since they don't allow 3rd party ASM)
-
Wasn't there that issue though on the 83+ when it came to flash. Can't certain functions only be done from page 0 in flash which the OS controls. I think one of them was unlocking the flash.
-
Wasn't there that issue though on the 83+ when it came to flash. Can't certain functions only be done from page 0 in flash which the OS controls. I think one of them was unlocking the flash.
Well, TI had to do that sort of thing because they allowed assembly programming. (Also to prevent accidental flash writes in case of OS glitches, I suppose). In the case of the Nspire, they didn't have to limit access to anything because their OS is the only C/ASM that ever runs.
-
Which would be a real reason to hate unofficial 3rd party ones. It's much less secure.
-
Which would be a real reason to hate unofficial 3rd party ones. It's much less secure.
But we can do much more awesome stuff with direct access to the hardware anyway. I know that I, for one, am not going to write malicious programs and I think nobody else in this community would, either. Thus Ndless is fairly safe IMO.
-
But, you could accidentally brick your own hardware through a small corruption in your code. That corruption could be as bad as intentionally malicious code, or even worse.
And I forgot to put "for TI" after reason. :P
-
But, you could accidentally brick your own hardware through a small corruption in your code. That corruption could be as bad as intentionally malicious code, or even worse.
And I forgot to put "for TI" after reason. :P
Actually, the most you can do is reboot the calculator, corrupt the boot2 (which can be resent via RS232 cable), or corrupt the OS (which can be resent via RS232 or USB). The last two will only happen if you're messing with the Flash memory.
-
Didn't someone find a way to alter boot1 thru ndless on here? Let me look up the thread...
Edit: here (http://ourl.ca/8594). look for NOR rom. Something about SD cards too....;D
-
Didn't someone find a way to alter boot1 thru ndless on here? Let me look up the thread...
There's a theory that it can be altered due to an option found in the diagnostics software. I don't believe it has been shown to be possible though.
-
I see Lua and C/asm as complementary: hopefully Ndless 3.0 will make possible to embed Lua scripts in Ndless programs, and extended the Lua API with native functions.
-
That would be pretty cool, but probably a significant amount of work :)
Besides embedding Lua scripts in Ndless programs, I think that for correct interaction between native code and the Phoenix math stack (especially, R/W access to variables embedded in the document), we'll have to figure out how to embed a Ndless document in a "normal" TNS document.
-
<< That would be pretty cool, but probably a significant amount of work >>
Probably not so difficult: Lua is designed to be embeddable and extendable. Finding out the Lua entry points in the OS is quite easy.
-
It would be nice if you figured that out ;D
-
That would be pretty cool, but probably a significant amount of work :)
Besides embedding Lua scripts in Ndless programs, I think that for correct interaction between native code and the Phoenix math stack (especially, R/W access to variables embedded in the document), we'll have to figure out how to embed a Ndless document in a "normal" TNS document.
That would be pretty cool! We could have game engines written in C, but modified by the way of lua scripts.
-
Is there currently a version of Ndless 3.0 in the works?
-
Is there currently a version of Ndless 3.0 in the works?
Thats somehing completeley unpredictable.
Finding bugs and exploiting them is an art and a science.
Its a time consuming trial and error process.
How much of your personal time to do this is a factor.
-
Is there currently a version of Ndless 3.0 in the works?
http://ndlessly.wordpress.com/ (http://ndlessly.wordpress.com/)
"The upcoming Ndless v3.0, compatible with OS 3.0, is under development, and I was hoping to share an alpha version soon"
-
That's good to hear.