I just started trying to learn assembly, and thought that I would test using it on the Prizm with this program:


Code:


Unfortunately, this doesn't even compile, and I get the following error:


Code:


From what I've read, GCC uses the AT&T syntax, so I'm not sure what is wrong here.

%eax is an x86 register, and movl is an x86 mnemonic. As noted on our Casio Prizm information page, the Casio Prizm has an SH3/4 processor, which means that you need to write SH3/4 ASM for it.

That code will run better on a Casio Algebra FX.

http://www.pageofmarco.de/afxinfo.php

It won't even then! 32-bit registers weren't introduced until the '386.

(We digress, though.)

I read about this calculator at Marcos' AFX site. Very interesting hardware and possibly an easier platform on which to develop.

Is this calculator still being made by Casio ?

I have been using this routine to help me learn prizm assembly (http://www.cemetech.net/forum/viewtopic.php?t=9740&highlight=), but I don't understand what is going on with the .align instructions:


Code:


From what I've read, (http://stackoverflow.com/questions/11277652/what-is-the-meaning-of-align-an-the-start-of-a-section) .align is used to optimize the placement of data, but must also be a power of two. What are the .align 1 instructions for? The code compiles without them, but it doesn't without the .align 2 instruction.

.align refers to placing data that are aligned on word boundaries. For example, .align 2 can place a value at addresses % 2 == 0, such as 0x8000, 0x8002, 0x8004..., .align 4 places values at addresses at % 4 == 0, such as 0x8000, 0x8004, 0x8008...

This is because opcodes for the Prizm that operate on words and dwords directly in memory may need to access values on aligned addresses.

Possibly .align sets the alignment state and .align 1 resets it? I haven't done anything in assembly for SuperH.

In the SH-4 and SH-4A software manuals it lists these three .align instructions:

.align 2
2-byte boundary alignment
.align 4
4-byte boundary alignment
.align 32
32-byte boundary alignment

However, it never mentions .align 1, nor is it used in any examples.

My guess would be that .align 1 is 1-byte boundary alignment. The reason it still works when you remove them is because 1-byte boundary alignment is meaningless.

The machine requires that memory accesses be aligned to their size, so byte access has no alignment restrictions, halfword (16-bit) requires that bit 0 of the address be clear, and word access requires that the low two bits be clear. Unaligned accesses cause a fault at runtime.

gas is unfortunately rather indecisive when it comes to interpretation of the .align directive; I'm assuming the alignment parameter for SH is in bits, since the docs don't call it out as a system in which the alignment is specified in bytes.

With that in mind, we can dissect it a bit:
Code:
We load a 16-bit value from memory at width into r1. Since it's a 16-bit load, we must ensure the value is aligned with bit 0 of its address clear.


Code:
Same deal, except it's a 32-bit value so must have the low-order two bits clear. The trailing align directive is useless- not only will the toolchain handle alignment for code as necessary outside this function, but a 4-byte-aligned value such as this one is also 2-byte-aligned by definition.

From what I've seen the docs do call it out as byte alignment.

".align 2
2-byte boundary alignment
.align 4
4-byte boundary alignment
.align 32
32-byte boundary alignment "

is directly from the SH-4A software manual. Another thing that confuses me about this code is the clrmac instruction. I understand it clears the multiplication accumulator, but in this version I re-wrote:

Code:

The accumulator isn't used, yet if the clear instruction isn't called the program causes the calculator to crash.

Official docs don't apply to GNU tools, which I assume you're using (since we don't use the official tools at all). I did some experiments, and it appears to be bitmask-based as I had guessed.

align.S:
Code:


Build:
Code:

Disassemble:
Code:


Now we can experiment with different alignments for the values and see what falls out.

A1=0, A2=0: packed as expected.
Code:


A1=1, A2=1: no change; all values are already aligned at even addresses.

A1=2, A2=1: assembler notices (!) and bails out; the value at A2 would be placed at offset 6:
Code:


A1=2, A2=2: both values aligned with bits 0 and 1 clear:
Code:


A1=3, A2=2: still a 16-bit gap between A1 and A2 values as expected, A1 is now pushed back 6 bytes to clear the lower 3 bits:
Code:


That seems pretty conclusive to me. A really obvious example with A1=4, A2=8:
Code:

That's because RTS has a delay slot, which means the following instruction is executed before actually returning. If you replace the CLRMAC with a NOP or the MOV.W instruction, I think it would no longer crash. (An RTS with nothing specified after is a bad idea, since you'll be executing an arbitrary instruction or data after it.)

How would I go about moving the value of a C variable into a register from an inline assembly block? I imagine it would involve finding the variable's location in memory, but I have no idea as to how that would be done.

You have to use some features provided by GCC inline assembly : http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#toc5
You can see here for exemple, section extended assembly .

If you want an exemple of how it works with SH asm, i've got a project where I use it in the add_byte function https://github.com/Nemhardy/chip8/blob/master/src/instructions.c
If you dont understand, just ask.

Édit: doing some correction because my grammar corrector doesn't handle English very well :p

No it isn't, and that is actually kind of sad. It was a really great calculator.

I am looking at one on a popular auction site. What cable is required to link between the calculator and a PC ? I have 9860 and the USB linking cable for that particular model but I guess the FX is different ?

It's standard USB mini-A AFAIK.

Edit: I misunderstood your question apparently, assuming FX -> FX-CG.

The AFX connects through 3-pin only. It doesn't have a USB connector and you'll need a special 3-pin<->serial cable (and eventually a serial-to-USB adapter if your computer doesn't have a serial port). See http://www.casiopeia.net/forum/viewtopic.php?f=20&t=1473

EDIT (reply to Tari): indeed, "FX" can refer to basically all the Casio calculators, even the scientific and very old ones.

Nemhardy; I followed your example and read that article on gcc inline assembly, but the code I've written doesn't work.


Code:


Do you have any idea what the problem is? it compiles fine, but when I run it on my calculator it causes a crash.