Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - NecroBumpist

Pages: 1 ... 6 7 [8] 9 10
106
Humour and Jokes / Re: 9001 signs you're addicted to calcs and Omni
« on: August 21, 2011, 12:42:13 am »
1930s: You're tempted to go out and buy another calculator despite the poor conditions of the current economy.

107
News / Re: Texas Instruments redesigns entire graphing calculator line
« on: August 21, 2011, 12:33:58 am »
Quote
God damn man, you fucked your shit up
They really confused the models there...

But this is interesting.
If TI is changing their marketing, it could mean a shift in where they want to take the company,
Maybe a new line of calculators ?
Maybe more love for the calc development community :)?

All of the above is just dreams, they probably just got bored and redid a small part of their website.

/speculations

Not that I actually now which is the 83/84/89, but:

108
Miscellaneous / Re: Do you know what Duplo blocks are?
« on: August 20, 2011, 10:56:40 pm »
After finally googling them, I can say I know them. I just can't remember the name  :-\

109
Miscellaneous / Re: Do you know what Duplo blocks are?
« on: August 20, 2011, 09:30:32 pm »
I haven't the slightest clue :)

110
Update to v2.2
Now includes NASM like macros:

Code: (Example LASM) [Select]
.options 0, 0, 0, 200 ; yay for large stacks!

.macro print(s, msg){
    getglobal   s,  <'print'>
    loadk       s + 1,  msg
    call        s,  2,  1
}

print   0, <"Omnimaga :)">      ; this line will be replaced with everything in the print macro (this is good for inlining functions and stuff)
return  0,  0

>Omnimaga :)

It took forever to get this shit working, mainly because of my terrible code layout :P

Anyway, v2.3 will include cool stuff like automatically tracking the top of the stack so you don't have to use .options in every prototype, and LOTS of linker stage checks. This will prevent (well, help you figure out) the common "invalid bytecode" warnings loadstring() returns if you try to load bad code.

More can be read in the README in the repository.


How exactly would we include this stuff in the actual script, though?

You'd use the loadstring() function to convert the code Assemble() returns into a proper Lua function, which you can easily call and pass arguments to from your normal scripts.

Code: (Use this code to generate bytecode) [Select]
local mods = require("current");
local code = mods.Assemble([[
; put cool Lua ASM code here
]]);

print(code:gsub(".", function(a) return "\\" .. a:byte() end)) -- turn the code into an escape sequence
Code: (Use this code in your production code, or what you put on the calc) [Select]
local code = "" -- copy and paste the output of the previous script here
local func = loadstring(code);
func()

111
Ndless / Re: Would Ndless 3.0 be possible through Lua?
« on: August 20, 2011, 05:23:33 pm »
Kofler is not the first person to think of the bugs listed on the Lua bug page ;)

* the first bug involves precompiled code - but third-party Lua TNS documents are plain text, so we can't feed malformed precompiled code into TI's stripped interpreter through that means;

This is entirely viable.
string.dump() returns the precompiled version of a function (as does luac.exe), which you can then execute with loadstring()

I know several of these precompiled attacks, one of the more promising being that when you call a function, you can retrieve the values it placed on the stack. Yesterday I briefly tested this attack on the D2Editor.new(), but all I found was a __gc() metamethod, which ended up crashing my calculator.
But, there are many C functions in the NSpire's API, and it's possible one of them could be of some use.
Once I finish an update for one of my projects, I'll go back to testing this method more thoroughly.

If I find something, should I just PM it to ExtendeD? Though I'm not even sure I would know what's useful and what isn't...

112
Humour and Jokes / Re: 9001 signs you're addicted to calcs and Omni
« on: August 20, 2011, 02:38:41 pm »
1917: You love it here despite being new :)

113
TI Z80 / Re: Pokemon Topaze (Axe)
« on: August 20, 2011, 02:36:52 pm »
Looks very nice :)
I hope you continue developing this!

114
Miscellaneous / Re: Birthday Posts
« on: August 20, 2011, 11:48:36 am »
Happy Birthday to you,
Happy Birthday to you,
Happpppy Birrttthhday dear JuJuuu,
Happy Birthday to you

And many more :)

115
Ndless / Re: Ndless for Nspire CX?
« on: August 20, 2011, 11:17:17 am »
What's the status on NDless 3 anyway ? Under development ?

116
Hmm Interesting. I unfortunately no longer am into programming but I'M glad to see more programming tools coming out. For which platforms will this be?
I've yet to run the assembler/linker on calc (the code is horendous (no planning), and it would be really slow for large files.

But I'm mainly posting it because you can utilize whatever code you assemble on any platform that runs Lua.
So basically the NSpire series :)

Looks real nice. So that means another programming language for the NSpire? (And maybe anything that runs Lua?) Cool.
I'm not sure I would call it an entire new language, since the code it produces is ran normally in Lua. It's just a more minimalistic version of Lua.
So if you do your planning, you could definetly organize your code in way that would be better than the standard Lua compiler.
How much better, I do not know.

It's similar to the coding in C vs. ASM for x86. The best C compilers are better than average ASM coders.
But then again, the Lua compiler really does no optimzations at all. Writing important functions in Lua ASM might be of benefit, but writing simple or non-time-critical functions would likely be a waste of time.

I plan to do an example with a SHA256 algorithm tomorrow, one in normal Lua, another specifically in Lua ASM.
(I'm going to use an external library, so it won't run on calc, but it will show how Lua ASM can be helpful)

117
Welp, I am in need of more posts before I can join the IRC apparently, so I will introduce you all to a project I'm working on :)

Since Lua is currently the fastest programming language for up-to-date NSpire calculators, I thought I would share this relevant project.
This really is for those who want to get the absolute most out of Lua. It's very impractical to write an entire program from Lua assembly, since the compiler does a decent job for most non-time-critical functions.

Lua is actually a semi-compiled language (at least that's what I'm going to call it).
It is compiled to bytecode, and than interpreted dynamically on a virtual machine.

You can execute Lua bytecode directly in Lua with the loadstring() function.

Code: (Example 1) [Select]
loadstring("\27\76\117\97\81\0\1\4\4\4\8\0\56\0\0\0\64\67\58\47\85\115\101\114\115\47\74\97\115\111\110\47\68\111\99\117\109\101\110\116\115\47\80\114\111\103\114\97\109\109\105\110\103\47\76\117\97\47\77\79\68\83\47\116\101\115\116\46\108\117\97\0\13\0\0\0\13\0\0\0\0\0\0\2\1\0\0\0\30\0\128\0\0\0\0\0\0\0\0\0\1\0\0\0\13\0\0\0\0\0\0\0\0\0\0\0")();

Now I'd go over the bytecode format, but you can learn all of that here
This document also includes all of the information on all of the instructions to the Lua VM.

Now, onto the project.
(In retrospect, the name I chose was rather silly, but meh, it applies)

Basically, it includes the following:
  • An assembler for a custom syntax of my own design (feature ridden)
  • Something I would call a Linker, that takes a table of all the relevant information, and compiles it into Lua bytecode
  • Soon to be a disassembler, which will turn a normal Lua function into Lua assembly.

You can find the repository here: https://github.com/NecroBumpist/MODS

So, time for "Hello World!" in Lua assembly
Code: [Select]
local mods = require("MODS.Current.main");
local bytecode = mods.Assemble(
[[
; Hello_World.lasm
.options 0, 0, 0, 2        ; a directive, which sets some properties, the '2' meaning MaxStackSize

getglobal    0,    <'print'>        ; <> denotes a constant, i've yet to bother with a directive for doing constants
loadk        1,    <'Hello World!'> ; The LuaVM is register based, we put the function in one register, then arguments above it
call         0,    2,    1          ; now we call register 0, with (2-1) parameters, accepting (1-1) values back
return       0,    0                ; and now we return
]]);

loadstring(bytecode)() -- turns the bytecode into a function, then we call that function

>Hello World!


So,  I'd like to hear what some of you Lua users who are looking for speed improvements think :)
I plan on updating the repository soon to include:
  • Write some proper documentation
  • Updates to the assembler to include NASM like Macros (debugging right now)

In ten or twenty minutes the repository should be much cleaner ;)

Comments, questions, or concerns ? Or Lua Assembly general thread.

118
General Discussion / Re: "The Planets" by Gustav Holst
« on: August 19, 2011, 05:08:49 pm »
Wow, I just watched Mars, and that was awesome.
I can't wait to watch the rest :D

I had the pleasure of seeing these performed live once, and I loved it.  Ah, the memories.

so much jelly, this like an amazing performance.

119
TI Z80 / Re: On-the-fly screenshots (homescreen only)
« on: August 19, 2011, 01:59:16 pm »

120
TI-Nspire / Re: Hyena: a simple (Lua) GUI library for the TI-Nspire
« on: August 19, 2011, 11:58:03 am »
Pretty cool, I might also try a basic window GUI library like this as well.
Also, dragging windows looks rather difficult on the touchpad, maybe you could change instead to holding a button like "ctrl", and pressing 4, 8, 6, or 2 will move the focused window left, up, right or down respectively ?
/suggestion

Pages: 1 ... 6 7 [8] 9 10