Sweet Barking Cheese, below is the compiler output for fibo. Of course my first test project is the blinking LED. It's always great to see a little LED blinking and think how much hard work get put it to make the compiler get to that point. And with the integrated Propellent downloader, click to build and it automatically downloads and run. Sweet!
To forestall questions:
- beta is very close. We are optimizing stuff
- the LED toggling is done using inline asm because effectively, the Propeller has two address space - COG RAM and HUB RAM. In the future, we will add a __COG keyword, mainly so we can access the IO registers in C (e.g. *(__COG int *)0x1F4 = ...). Until then, we decide to let casting of constant address as HUB address, assuming that's what people would want (I don't know, SD driver buffer, multi-threading hook) so inline asm is needed to access COG IO registers.
- all the .dbXXX are pseudo-ops for .lst listing file generation, and more importantly, future debugger use
> so inline asm is needed to access COG IO registers
inline ASM? The more I think about it, the more I get puzzled.
Does that work? And if yes, in the same cog running the C-code? And again if yes, that will certainly reduce the code size.
Or do you mean someting different with inline asm than I do?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.: YADRO
Nick,
This is LMM code. There's an interpreter that copies instructions into the cog, one at a time, and executes them in-line in the interpreter. The C is compiled to these "assembly" instructions, so in-line assembly just gets copied into the generated assembly code.
I copied the code, re-formatted it and removed the debugging info to get a better idea of what the fibo() code was doing. To save others the effort ...
Comments
To forestall questions:
- beta is very close. We are optimizing stuff
- the LED toggling is done using inline asm because effectively, the Propeller has two address space - COG RAM and HUB RAM. In the future, we will add a __COG keyword, mainly so we can access the IO registers in C (e.g. *(__COG int *)0x1F4 = ...). Until then, we decide to let casting of constant address as HUB address, assuming that's what people would want (I don't know, SD driver buffer, multi-threading hook) so inline asm is needed to access COG IO registers.
- all the .dbXXX are pseudo-ops for .lst listing file generation, and more importantly, future debugger use
***
.area text(rom,rel)
.dbfile fibo.c
.dbfile C:\WORK\v7\examples.prop\Fibo\fibo.c
.dbfunc e ToggleLED _ToggleLED fV
; i -> R0
_ToggleLED::
@FENTER
.long R15,0
.dbline -1
.dbline 2
; void ToggleLED(int i)
; {
.dbline 3
; i = 1 << i;
mov R15,#1
shl R15,R0
mov R0,R15
.dbline 4
; asm("mov DIRA,%i");
mov DIRA,R0
.dbline 5
; asm("xor OUTA,DIRA");
xor OUTA,DIRA
.dbline -2
L1:
@FPOP
.long R15,0
@FRET
.dbline 0 ; func end
.dbsym r i 0 I
.dbend
.dbfunc e fibo _fibo fI
; n -> R4
_fibo::
@FENTER
.long R4,R14,R15,0
mov R4,R0
.dbline -1
.dbline 10
; }
;
;
; int fibo(int n)
; {
.dbline 11
; if (n <= 1) return n;
cmps R4,#1 WZ WC
IF_A rdlong PC,PC
.long L3
.dbline 11
mov R0,R4
rdlong PC,PC
.long L2
L3:
.dbline 12
; return fibo(n - 1) + fibo(n - 2);
mov R0,R4
sub R0,#1
@FCALL
.long _fibo
mov R15,R0
mov R0,R4
sub R0,#2
@FCALL
.long _fibo
mov R14,R0
mov R0,R15
add R0,R14
.dbline -2
L2:
@FPOP
.long R15,R14,R4,0
@FRET
.dbline 0 ; func end
.dbsym r n 4 I
.dbend
.dbfunc e main _main fI
_main::
.dbline -1
.dbline 16
; }
;
; main()
; {
.dbline 17
; ToggleLED(16);
mov R0,#16
@FCALL
.long _ToggleLED
.dbline 19
;
; fibo(29);
mov R0,#29
@FCALL
.long _fibo
.dbline 20
; ToggleLED(16);
mov R0,#16
@FCALL
.long _ToggleLED
.dbline 21
; ToggleLED(23);
mov R0,#23
@FCALL
.long _ToggleLED
.dbline -2
L5:
@FRET
.dbline 0 ; func end
.dbend
i am getting the hots already.
how good to see main and braces at last.
MikeW
What do you mean "at last"?
You can already have all he main and braces you need on the prop, see my "CP/M for propeller" thead.
Strangely I don't have many takers for it. Maybe it's a bit slow...
Seriously though, this is great stuff by ImageCraft.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
must have missed your thread.
I was probably off playing golf, like Gary Kildall. -
I had my 59th birthday on Monday, so I remember it all.
MikeW
I thought he was flying a plane?>
inline ASM? The more I think about it, the more I get puzzled.
Does that work? And if yes, in the same cog running the C-code? And again if yes, that will certainly reduce the code size.
Or do you mean someting different with inline asm than I do?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
This is LMM code. There's an interpreter that copies instructions into the cog, one at a time, and executes them in-line in the interpreter. The C is compiled to these "assembly" instructions, so in-line assembly just gets copied into the generated assembly code.
seems he was flying a plane to deliver s/ware product. ( see http://en.wikipedia.org/wiki/Gary_Kildall )
maybe his "propeller" was running a little slow; according the the wikipedia piece "Gary returned in the afternoon".
if he had had a propII, he would have been back before lunch, and met IBM !!
Thus the course of history could be changed with a propellerII
Mike
_fibo: cmps R4,#1 WZ WC IF_A @JMP L3 mov R0,R4 @JMP L2 L3: mov R0,R4 sub R0,#1 @FCALL _fibo mov R15,R0 mov R0,R4 sub R0,#2 @FCALL _fibo mov R14,R0 mov R0,R15 add R0,R14 L2: @FPOP R15,R14,R4,0 @FRET