Very late reply - but if anybody is still interested - I'm one of the '5'.
the very very basic - get started in assembler on pine 64:
Set up the pine 64 with debian - not going near bare bones here - that's way down the road.
open a terminal session.
at the $ type : (and note the spaces at the beginning of the third and fourth lines.
cat > test1.s
.global main
main:
move x0, #3
blr x30
^D (i.e hold ctrl and hit 'D')
... and you get your $ back
.. and you can use vi or any other editor to create the program, of course.
So we have typed a two instruction 64-bit assembly language program which has an entry point defined (main) and exits back to the calling program (we'll see why in a mo...).
test it by calling the assembler :
as -o test1.o test1.s
(fix any errors that occur - should be just typos)
then link it to the core c libraries for basic calling and return support
gcc -o test1 test1.o
(note simply typing 'make test1' will actually do the same as both of these - but explaining why is a whole new topic - and in this case obscures the two step assemble then link process)
and finally run it :
./test1
if you've done it right you see the $ again.
to verify the program did something type
echo $?
and you should see a '3'
(this is the #3 from our third line.)
OK so what's happenned here ?
we declared a program location called main as global - this means other things can see it - calling it main is key as that is what the linker needs to find to pass control to.
Then we defined where main should start executing.
We then loaded the number 3 into the first of the 31 64-bit registers (called X0) - and we did this because when our program finishes that is where the system expect to find our return code. Then we executed a branch to a location in the 31st 64 bit register (called X30)- and we did this because that is where we expect the OS to have put the address to which we return when finished.
... and it worked because the program completed and we got our $ prompt back and when we checked the return code we saw a three which we had intentionally sent back as the return code in x0.
OK so it does all work - but to progress you need to learn the ARMv8-A assembly language and you need to understand the structure of the processor.
check the two pdf links in rahlquist's post above and also find :
ARMCT_armasm_reference_guide_v6_01_DUI0802B_en.pdf (it's on the Arm site - use google).
Ok so from here on it's just learning the assembly language - and the debugger (gdb) so you can see what's happenning - and you also need to understand that there are rules you have to follow - in the same way that the X0 is where we have to put our return code and X30 is where we have to return to - you need to ensure that don't overwrite your own return address or you can't successfully return control to the OS - there are docs out there which will help. And the slightly good news is that the linker links in some key c routines like printf and scanf which allows our program to get user input and send user output by calling these routines with the approriate values in registers/memory.
Typed into midori while validating it live on my Pine 64.
Only found this post when I was trying my pine 64 with some Arm 7 code I had written for a Raspberry Pi - which failed miserably a few minutes ago - and then I realised duh - 64 bit. But migrating in principal is not a big deal - but in detail the assembly language is quite different.
There is a very good intro to Arm 7 for Raspberry pi at
http://thinkingeek.com/2013/01/09/arm-as...chapter-1/
clearly the assembly language is different - but the key messages in the first few chapters are the same.
(the docs above outline the differences between the 32bit and 64bit instructions sets)
Finally - I don't believe this will work on a RasPi3 - I believe that it runs in the 32-bit mode -and mode switching is a few steps down the road - but I will check now that my curiosity is engaged.
the very very basic - get started in assembler on pine 64:
Set up the pine 64 with debian - not going near bare bones here - that's way down the road.
open a terminal session.
at the $ type : (and note the spaces at the beginning of the third and fourth lines.
cat > test1.s
.global main
main:
move x0, #3
blr x30
^D (i.e hold ctrl and hit 'D')
... and you get your $ back
.. and you can use vi or any other editor to create the program, of course.
So we have typed a two instruction 64-bit assembly language program which has an entry point defined (main) and exits back to the calling program (we'll see why in a mo...).
test it by calling the assembler :
as -o test1.o test1.s
(fix any errors that occur - should be just typos)
then link it to the core c libraries for basic calling and return support
gcc -o test1 test1.o
(note simply typing 'make test1' will actually do the same as both of these - but explaining why is a whole new topic - and in this case obscures the two step assemble then link process)
and finally run it :
./test1
if you've done it right you see the $ again.
to verify the program did something type
echo $?
and you should see a '3'
(this is the #3 from our third line.)
OK so what's happenned here ?
we declared a program location called main as global - this means other things can see it - calling it main is key as that is what the linker needs to find to pass control to.
Then we defined where main should start executing.
We then loaded the number 3 into the first of the 31 64-bit registers (called X0) - and we did this because when our program finishes that is where the system expect to find our return code. Then we executed a branch to a location in the 31st 64 bit register (called X30)- and we did this because that is where we expect the OS to have put the address to which we return when finished.
... and it worked because the program completed and we got our $ prompt back and when we checked the return code we saw a three which we had intentionally sent back as the return code in x0.
OK so it does all work - but to progress you need to learn the ARMv8-A assembly language and you need to understand the structure of the processor.
check the two pdf links in rahlquist's post above and also find :
ARMCT_armasm_reference_guide_v6_01_DUI0802B_en.pdf (it's on the Arm site - use google).
Ok so from here on it's just learning the assembly language - and the debugger (gdb) so you can see what's happenning - and you also need to understand that there are rules you have to follow - in the same way that the X0 is where we have to put our return code and X30 is where we have to return to - you need to ensure that don't overwrite your own return address or you can't successfully return control to the OS - there are docs out there which will help. And the slightly good news is that the linker links in some key c routines like printf and scanf which allows our program to get user input and send user output by calling these routines with the approriate values in registers/memory.
Typed into midori while validating it live on my Pine 64.
Only found this post when I was trying my pine 64 with some Arm 7 code I had written for a Raspberry Pi - which failed miserably a few minutes ago - and then I realised duh - 64 bit. But migrating in principal is not a big deal - but in detail the assembly language is quite different.
There is a very good intro to Arm 7 for Raspberry pi at
http://thinkingeek.com/2013/01/09/arm-as...chapter-1/
clearly the assembly language is different - but the key messages in the first few chapters are the same.
(the docs above outline the differences between the 32bit and 64bit instructions sets)
Finally - I don't believe this will work on a RasPi3 - I believe that it runs in the 32-bit mode -and mode switching is a few steps down the road - but I will check now that my curiosity is engaged.