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.
Topics - AngelFish
Pages: 1 2 3 [4] 5 6 ... 8
46
« on: May 26, 2011, 05:09:42 am »
Recently, Tari on Cemetech posted a short piece about programming Assembly for C libraries. In order to generate libraries usable in C programs, a specific format must be used. First of all, the registers are each assigned the following uses by GCC:
- r0-r1 Stores function return value, caller saves.
- r2-r3 Scratch space, caller saves.
- r4-r7 Function parameters, caller saves.
- r8-r13 Scratch, callee saves.
- r14 Frame pointer, callee saves.
- r15 Stack pointer, callee saves.
- MACH,MACL Callee saves.
If an argument is more than 32 bits long, it's pushed onto the stack rather than split amongst different registers.
The format for a function in such a library is to declare the function global with the .global tag. An example of this would be this function to return the jump to a syscall:
.global _Syscall
/* Syscall(short <syscall number>) */
/* Jumps to the syscall */
mov.l Table,r2
shll2 r4
mov.l @(r4+r2),r0
jsr @r0
nop
nop
Table: .long 0x805EDCA8
The code is then included in the compiled code with the #include <example.s> declaration.
Using this, I've been working on a few libraries recently to help with some of GCC's weak areas and other speed critical functions.
Partial list of implemented and planned functions for my math library (which I've actually had around for quite some time):
Modulus
Arbitrary precision addition
Arbitrary precision subtraction
Arbitrary precision multiplication
Arbitrary precision integer division
Hardware division
64 bit operations
Single precision Floating point operations
OS variable floating point operations
Integer Square root
Integer inverse square root
Floating point -> integer conversion
Integer->Floating point conversion
Floating point Absolute value (it's like two lines, but whatever :p)
47
« on: May 05, 2011, 06:08:15 pm »
Have you ever taken a test (or just realized in general) that some of the methods taught in school are very tedious and there's a much faster way to do precisely the same thing? For example, one of the things taught in both Statistics and Linear algebra is finding a least squares regression line for a given data set. Statistics teaches you how to solve:  while Linear algebra teaches you a very computationally intensive, often poorly explained method involving matrix operations. While I was taking my Linear algebra final today, I realized that instead of solving those messes, the least squares regression line is actually a weighted "Average" of several other functions that depend on the values of the data set for the linear case, although it doesn't extend to higher order regressions. Thus, my answer took half a page to derive instead of the two pages given to solve the problem on and involved only very simple arithmetic to do the problem. Has anyone else ever had a similar experience?
48
« on: May 03, 2011, 11:11:25 pm »
Welcome to the new age of Prizm programming. There have been a lot of new program announcements and recent developments in the Prizm community. As was recently announced on Cemetech, the Gnu C Compiler (a part of the GCC or Gnu Compiler Collection) has been demonstrated successfully compiling C programs for the Prizm. Although the new compiler brings several new capabilities to Prizm developers such as 64 bit data types and several new languages, its main advantage is that it does eliminate the developer dependency on the Casio fx-9860g SDK hosted by a third party site (now removed). Another exciting development is the release of a new version of Insight by SimonLothar. This new release demonstrates additional capabilities on the Prizm including animations. Here's a screenshot taken by forum founder DJ_Omnimaga: Other notable projects are the Prizm port of Obliterate by KermMartian and a Java Virtual Machine and interpreter framework. Additionally, rumors and evidence abound of several new compiled languages currently under active development by multiple members in both the TI-Prizm community and the Casio-Prizm community. A screenshot of Obliterate  Only the future will tell what amazing programs will be released. Stay tuned and keep your Prizms ready!
49
« on: April 29, 2011, 07:40:06 pm »
As some of you know, GCC for Prizm has been delayed a few days because of a bug in the assembly of some RAM initialization code. For some reason, the file crt0.s (the source) is generating interrupt errors when compiled with GCC, but not when compiled with the fx-9860 SDK and Hitachi's compiler. We've been looking at it for some time and it's not immediately apparent what the difference is. Any help would be appreciated.
50
« on: April 28, 2011, 09:31:31 am »
After a lot of trouble, I've finally managed to get Linux to install on my computer. However, I've noticed some problems with it. Perhaps the worst are those related to authentication: Essentially, everything about authentication and sudo is bugged for me. For example, when installing certain plugins, authentication is required to install. I can type in the password and it will accept it, but the text boxes close and the "next" and "Cancel" buttons simply stop workng . The only buttons that do work are the minimize, maximize, and close window buttons. It's even worse with sudo from the terminal, since that won't let me even type in the password to verify.
This is for Ubuntu 10.10, brand new, almost nothing on it.
Any suggestions?
51
« on: April 27, 2011, 01:48:00 am »
Given a function f(x) that operates on the set of whole numbers, for every x n, there is a corresponding y n in the set of integers that is equal to the function applied to the integer x n. x|y --- 1|1 --- 2|3 --- 3|7 --- 4|13 --- 5|31 --- 6|49 --- 7|115 --- 8|215 --- 9|509 ... What is the function f(x)? More generally, what is the value of y for any integer x n? Hints (since this is likely to be difficult): - The function is only defined for positive integers. However, it is defined for *all* positive integers.
- The function does in fact follow the general upwardly trend that you can see. It's not a pathological function that will go insane the second you extend the values. However, there are two arguments to the function, one of which I have kept constant simply because the equation is too chaotic if it's allowed to change.
- This isn't a standard type of function, so any answer that correctly predicts the subsequent terms of the sequence will be accepted
- It doesn't involve Nethams. I'm serious.
53
« on: April 22, 2011, 03:19:58 am »
It's taken awhile, but we finally have a working assembler.  The Gnu Assembler, which has supported SuperH processors for some years has finally been compiled by Jonimus for Prizm use and was announced at the last HWCP. However, the syntax is a bit odd. After spending multiple hours playing around (read: me kicking my computer until it assembled correctly) with the assembler, we've finally managed to get it to properly assemble the binaries. Here are some examples of the syntax: stc vbr,R1
mov.l bar,R2
mov.l bur,R3
bsr next
next: add R1,R2
mov.l R3,@-R2
sts pr,R4
.word 0x7408
.word 0xC301
nop
nop
nop
bar: .long 0x00000100
bur: .long 0x0000000B
nop
nop
nop
nop
/* comments*/
-----------------------
Assembled code:
0122
D205
D305
BFFF
321C
2236
042A
7408
C301
0009
0009
0009
0000 0100
0000 000B
0009
0009
0009
0009
stc.l sr,@-R15
mov #0x01,R9
mov #0x01,R10
add R8,R9
add R8,R10
mov #0x01,R13
Loop:
mov.l @R9+,R11
mov.l @R10+,R12
cmp/eq R11,R1
bt/s jump
add #0x29,r13
tst R13,R13
bt/s return
nop
bra jump
nop
jump:
nop
return:
nop
nop
/* Comment */
-------------
Assembled code:
4F03
E901
EA01
398C
3A8C
ED01
Loop:
6B96
6CA6
31B0
8D05
7D29
2DD8
8D03
0009
A000
0009
jump:
0009
return:
0009
0009
However, while it will assemble correctly under certain circumstances, it is extremely fussy about the quality of the code. As a general rule, if it throws a single error, no other portion of code will have assembled correctly. It's pretty much all or nothing. Also, the comments at the end are there because the assembler complains if they're not. Happy hacking  sh3eb-elf-as.exe Assembler
54
« on: April 19, 2011, 02:35:22 pm »
As many of you have seen, there has been a recent upsurge in the number of games available for the newest calculators, the Casio Prizm and the TI-Nspire CX. The introduction of these calculators has gotten the community into a bit of a buzz because of their unprecedented color screens. A recent poll here on Omnimaga and on Cemetech indicated that ownership of these devices is roughly equal among members, suggesting that the recently reborn Casio community will remain prosperous for some time to come. Each device currently offers different things: On the Nspire CX, C and Assembly programming is still not widely available, but the OS includes a new interpreted language called Lua. The Prizm, on the other hand, has almost unrestricted programmability, but the only languages thus far are Assembly and C, both of which have been successfully demonstrated. Here are some example of notable projects from both sides: Casio Prizm:
Obliterate, a port of Kerm Martian's popular Obliterate game for the 84+ and 84+SE calculators. Minesweeper, a port of the perennial computer game everyone has spent at least a few hours trying to beat. PrizmLife, a simulation of Conway's famous cellular automaton. Java, a native port of the Java Virtual Machine to the Prizm. A video of the Conway's Game of Life clone:
TI-Nspire CX:Block Dude in Lua, a re-write of Block Dude in Lua. 15 Puzzle, Goplat's clone of his 15 Puzzles game. ExtendeD has also done a game called 9sweeper which is an Nspire port of Minesweeper.
55
« on: April 16, 2011, 07:13:29 pm »
Just a small survey to see what how many people own TI-Nspires or Casio-Prizms. Please be honest and don't double vote (Lobsters with pink usernames not allowed to vote)
56
« on: April 09, 2011, 06:58:33 pm »
Since I've noticed a lot of interest in microprocessors here, I thought it was time someone put up a simple tutorial on microprocessor design. I don't claim to be anything even remotely resembling an expert on the subject, but I think I have enough knowledge to demonstrate the basic design principles. To get started, you first need an electronics simulator. I recommend Logisim for a simple free program. However, I will not be using Logisim in these tutorials because I'm not as familiar with it and to encourage understanding of the fundamental concepts rather than the simulator. The principles and circuits will be identical, though. Also, some of the images are mine, some are from Wikipedia and other sources. Citations are not included because the circuits themselves are not copyrighted content. The first thing to understand when designing your own microprocessor is that you're not going to be making the next Intel i7 chip clocking 2.25 GHz on your first attempt. Commercial microprocessors often rely on advanced hardware optimizations and design principles that are beyond the scope of anything short of a graduate level design course. After you accept that, processor design isn't quite the black magic it's often portrayed to be. Like programming, it's mostly a matter of understanding the interactions between different subsections of the hardware. Logic gatesThe most basic components of all of the electronic circuits we will be dealing with are logic gates. Logic gates are basically devices which produce outputs that are a logical function of their inputs. There are seven types of logic gates, each represented by the symbol next to it. | AND |  | | OR |  | | NOT |  | | NAND |  | | NOR |  | | Exclusive OR (XOR) |  | | Exclusive NOR (XNOR) |  |
The inputs to logic gates take the physical form of voltage levels, most commonly 0 V and +5 V (other values can be used but the exact values aren't important). By convention, these voltage levels are referred to as representing the binary values 0 and 1 respectively. The logic gates operate on these inputs according to their Truth tables. When the input combination matches an input combination on the left hand side of the corresponding table, the output is the same as that which appears on the right hand side of the table. For example, when the input to a NOT gate is 1 (+5 V), the output of the NOT gate is 0 (0 V). CircuitsLogic gates are by themselves interesting, but there's no logic gate that implements say, a Z80 processor. This is because processors are composed of a lot of individual logic gates working together to accomplish the tasks required. So, let's start designing some small circuits that can do more than our individual logic gates. 1-2 Multiplexer (MUX): This device takes 2 data lines and an address line and places the value of of the data line whose address is equal to that of the address line on the output line.  2-1 Demultiplexer (DeMUX): This performs the inverse operation to a MUX. It takes one data line as well as an address line as inputs and places the value of the data line on the output line whose value is equal to the value on the address line.  Half adder: The half adder circuit takes two binary inputs and performs a binary addition on them. This produces two outputs, a sum and a carry-out.  Full adder: A full adder does the same thing as a half adder except that it also adds a carry-in bit to the operands.  There are many other types of circuits, but these simple ones will eventually form the basis of our microprocessor. Basic MemoryAs any search through an electronics forum will reveal, memory is one of the most important parts of a computer. Like any important material, there are also a billion ways to accomplish its function. The most common are through what are known as flip-flops and latches (which are essentially the same thing). The most basic memory cell is known as an SR NOR latch and the circuit diagram is this:  While this looks simple, it has a few fundamental flaws. For one thing, the set and reset inputs are on two different lines. That's not ideal, since we will almost certainly be wanting to store data from a single line at some point. Secondly, what happens if both the set and reset lines are active at the same time? Does it set or reset? Well, we don't know. This is an example of a "Race condition" and it's a very bad thing to happen to a memory circuit. The cell goes into a state of indeterminacy and we have no way of predicting what the final state will be. So, let's look at something else called the synchronous J-K flip-flop: The J-K Flip-flop avoids the disastrous race condition from the SR latch, but it still has those two annoying set and reset lines. As it turns out, if you replace the first level NAND gates with AND gates and the second level NAND gates with NORs, you end up with something called a T flip-flop (where T stands for Toggle...).  The T flip-flop is definitely a step in the right direction, since we have only 1 data line (and a control line), but what if we don't want to toggle the bits every time the data line is active? In that case, you must go with something called a D flip-flop. D latches are the most commonly used type of solid state memory in existence today and will likely form the basis for most of our processor's memory.  The D latch is perfect for most purposes you will ever come across, but it turns out that you can optimize in many circumstances. The truth tables for each of these circuits can be found here. The ALUAt this point, we have every circuit we need to build a computer that can perform any computation we wish. For the sake of simplicity, however, let's limit ourselves to something more reasonable: a four bit microprocessor. One of the most important parts of any processor is the Arithmetic Logic unit, or the ALU. The function of the ALU is basically to perform all of the arithmetic and logical operations within the processor. As you can imagine, processors like the Intel i7 with floating point trigonometric instructions have extremely complex and powerful ALU's. Since we don't have supercomputers to generate our circuit diagrams, we'll go for something easier to draw and understand. Before we can begin designing it, though, we need to know what it will have to do. In keeping with a simple design, we'll limit it to addition, subtraction, AND, OR, NOT, XOR, NOP and logical bitshifts. This might seem limited, but it's actually all you need to have a fully functional computer (although technically we could reduce the instruction set even further without reducing power). One thing that some people may notice is that addition and subtraction can be combined into one operation through the use of what's called Two's complement notation. While this is certainly possible for us, it would require that we dedicate one bit to be the sign bit. That's 25% of our operands dedicated exclusively to sign. Since the processor uses so few bits, we'll instead use dedicated circuits for addition and subtraction. Next: Putting it all together
57
« on: April 06, 2011, 08:12:43 pm »
Some people may have noticed that in the past few days, I've shut down all of my announced projects. This is not because I am quitting calc programming. Instead, it is because I am cutting out the programs that I cannot work on to make more room for other projects. Here is one such project: Black Here are some preliminary screenshots:
58
« on: April 06, 2011, 12:32:08 am »
I found a neat little tool on-line that translates things into other languages and back to English to see what happens. "If you were thinking about someone while reading this, you're definitely in Love." turns to "If you dare, read March" "Life is like a box of chocolates." turns to "Chocolate is a place to live." "What is Omnimaga?" turns to "Omunimaga?" "My calculator runs WFRNG." turns to "WFRNG running my calculator." to "VFRNG game." http://www.cheatingtranslators.com/bad-translator
59
« on: April 04, 2011, 06:04:06 pm »
One of the things I've noticed lately is that there is some level of language superiority among programmers. While this is not restricted in the least to members within the calculator community (programmers are actually worse on many forums that I've seen), this post was nonetheless written for that niche group. Programming is, at it's very core, the art of writing instructions to be carried out by a deterministic machine. This is the underlying concept of programming and all languages necessarily adhere to it. It also easily defines the various levels of programming. At the most basic level, one can program in the machine's native language of Binary (or Hexadecimal, if you prefer the easy way out). This was an extremely common form of programming in the early days of computers, but was quickly replaced by higher level logical abstractions. The first of these was the family of languages known as Assembly. Assembly essentially takes every binary instruction recognized by the underlying circuitry and replaces it with an easier mnemonic that generally describes what the instruction does that is translated to machine code by an Assembler. This allows programmers to work more quickly and easily with the logical abstractions of the mnemonics rather than the machine code. The advantage in using either of these languages is that no program can ever be performed more efficiently than by a program written in them. For any given processor, an optimal assembly or machine code program is necessarily at least efficient as a functionally identical program in any other language and often more so (in addition to being the fastest programs possible). Furthermore, all instructions on a processor are available for use (and thus all programs are possible in ASM/Hex). In many higher level languages, these instructions are not usable, which can result in much unnecessary work in writing code such as mathematical operations without machine word sizes. Of the two, Assembly language is the easier, but machine code offers some other advantages as well. For one thing, Assemblers may generate errors on otherwise valid code. Machine code will only ever return an error if the hardware (or emulator) can't handle the code. Secondly, the style of programming known as Self-Modifying Code is significantly easier in machine code than in Assembly. This often results in highly efficient programs, even above normal Assembly. Finally, Machine code has almost no "compilation" time. Whenever the code is ready to be tested, it can be copied/pasted into the executable and run. After Assembly came the first major jump in abstraction: the compiled language. Compiled languages replace the oftentimes obscure syntax of machine code and Assembly with that of a higher level language containing instructions that don't necessarily correspond to hardware level instructions. The program which translates these instructions to machine code (called a compiler) uses routines of lower level code to synthesize these high level instructions. A good example of such a language is C. As a language, C offers a wide variety of commands and instructions in order to do many different tasks, most of which are not available directly in lower languages. This high degree of logical abstraction allows programmers to work more quickly on many common tasks and generally avoid having to program difficult things such graphics. However, contrary to popular belief, it does NOT increase portability. Compiled programs are turned into machine code, so unless they're compiled on-site by the user (often not the case), they are no more portable than an appropriately written ASM/Hex program. Compiled programs are often extremely fast, but still lower and less memory efficient than an equivalent program written by a [skilled] ASM/Hex coder. Beyond compiled programs (which often have obscure syntax themselves) come interpreted programs. Interpreted programs are parsed at runtime by a program known as an interpreter, which contains all of the valid routines for that language. The advantage of interpreted languages is that they typically offer extremely simple syntax compared to other types of languages and even higher level instructions. However, this comes at a significant price. Since the interpreters must be kept in memory and parse the program at run-time, interpreted languages often have very high memory footprints and are generally much slower than compiled or assembled languages. Misconceptions:There are a few common misconceptions about these languages that I'd like to address as well. Machine code: Hexadecimal (I'm not aware of anyone who programs in Binary) is often regarded as impossibly complex and unwieldy to program in. This is, at least in my experience, no the case. Rather, it demands a different mentality in programming than almost all other languages. Another common misconception about Hexadecimal is that it doesn't allow convenient program formatting. This is in fact not true. I offer up my own code as an example 6323 //Store A to second variable
3308
E420
001A //Start division
74FF
3104
2448
8FFB //End division
4324
3325
021A //Move answer back to R2It may look complicated and obscure, but to an experienced Hex coder (which I am not), that should be reasonably obvious as B = (A-N)*(A/N). It also demonstrates the use of comments in hex programming, something that many believe to be impossible. Use of the backspace key to remove those is encouraged before pasting into an executable. Assembly: Assembly is often regarded as obscure and irrelevant as a language. On many programming forums, questions concerning how to do certain things in Assembly are almost inevitably greeted with at most one or two reasonable responses and a minimum of six posts saying "Why r u using that! try using ruby or c." Frankly, this astounds me as there can be very good reasons for using Assembly (good luck fitting the Python interpreter in the 4 KB of RAM on the Apollo 11 computers, buddy). However, as was stated earlier, Assembly is also the fastest possible language on a processor. That means that any other language can at most be as fast as a well written Assembly program. If Windows were written in Assembly, it'd probably run significantly faster in many places. It'd also have twice as many bugs and only come out around once a century, but those are other matters  Another common misconception of Assembly is that it's slow and painful to write. While more time is certainly spent in initial debugging, a skilled Assembly programmer can often rival a good programmer in a higher level language with most of the difference merely due to typing. Compiled languages: Compared to ASM and Machine code, compiled languages are typically slower and less memory efficient. However, they offer significant advantages to programmers. For one thing, the nature of the hardware is much less important than it is in Assembly or Machine code. The programmer is also not required to have an intimate knowledge of many common algorithms because they are provided through routines in the language itself. Most importantly, however, they allow for relatively fast program design and the management of massive projects without getting bogged down in processor details. To use the earlier example, if Windows was written in a compiled language, it would be slower and kind of memory hungry, but come out on a reasonable release schedule and not have as many bugs. All of these are of course true since Windows is in fact compiled. Compiled languages also make problems that would be a nightmare in lower languages such as the coordination of the 3000 some processors composing IBM's Watson possible at an acceptable speed. No Assembly programmer in their right mind would hesitate to say that such a complex problem is almost always better left to a higher level compiled language. Probably the most common misconception of compiled languages is that of "the compiler is always right." Some programmers genuinely believe that compilers produce optimal code. Frankly, that couldn't be farther from the truth. Modern compilers are extremely good at producing efficient code, but they are not and nor will they ever be (in the near future) better the task than humans. One particular case of this misconception that I remember is that of a redditor who, when faced with the challenge of designing a circuit with the minimum number of gates necessary to compute Conway's Game of Life, offered up the explanation to "just compile some vhdl with no timing and strict area constraints." The error in this suggestion should be obvious. Interpreted languages, while conceptually similar to compiled languages, tend to occupy a niche in the programming marketplace that makes them distinct from compiled languages. One of the most prevalent misconceptions surrounded interpreted languages is that they're slow and inefficient. While this can indeed be true, many modern interpreted languages are quite fast and powerful if the considerations are adjusted properly. They typically don't achieve the speeds of compiled languages, but they're also typically higher level and thus must often deal with more computationally intensive operations than compiled languages. The main advantage of interpreted languages, TI-BASIC in particular, is that they are extremely easy to quickly mock up complex programs and algorithms in. Furthermore, the lack of compilation time makes them valuable for testing purposes. It also turns out that the lack of speed may be a good thing for many programmers' education, for there's nothing for forcing you to learn how to optimize like trying to squeeze that last bit of speed out of your quadratic solver. Anyway, this is probably enough, as I'm pretty sure I have a giant wall of text by now... EDIT: 1583 words!
60
« on: March 30, 2011, 12:34:24 am »
One of the advantages of the TI Nspire CX over the Prizm is the greater range of math functions. This is a program designed to remedy that and help increase the mathematical capabilities of the Prizm. The secondary goal of the program is to demonstrate that while games may be fun to program and play, calculator programming can have useful applications and the encouragement of such programming is a benefit to educators rather than a detriment. In order to help facilitate these lofty goals, this program will include a wide variety of functions not provided in the Prizm's native OS such as the Gamma Function, extending the trigonometric functions to complex arguments, and numerical solutions to differential equations. The program itself interacts with the user through the console that easily allows the user to enter complicated mathematical functions with a re-defined keypad. Here is a demonstration of the keypad and a rudimentary parser interface: PS: Sorry for the blurry quality, but using pixels to record pixels doesn't exactly work very well... The equations: Sin(89) Sin(Cos(89Tan(97))) 89+3 Log(36+Sin(6))
Pages: 1 2 3 [4] 5 6 ... 8
|
Show Posts
