Author Topic: Assembly Programmers - Help Axe Optimize! (Read 156958 times)

yrinfish · « **Reply #210 on:** June 17, 2011, 12:29:04 pm »

why not // ? is that already something?

* yrinfish checks the new wiki

ah, it is...

what about ./? the dot is a 'point' and .* for multiplication

Munchor · « **Reply #211 on:** June 17, 2011, 12:34:09 pm »

Quote from: yrinfish on June 17, 2011, 12:29:04 pm

why not // ? is that already something?
* yrinfish checks the new wiki

ah, it is...

what about ./? the dot is a 'point' and .* for multiplication

I like ./ because it's fixed-point division.

And // is probably bad because of the way Quigibo made Axe.

Runer112 · « **Reply #212 on:** June 17, 2011, 12:35:24 pm »

Since it's fixed point division, how do you think /. looks? I think that operator is actually sort of logical with the decimal point. And although I don't know if you would want to change the fixed point multiplication operator and break compatibility with old programs, I think *. would make a great complement.

Ninja response to Scout: I think the division/multiplication operator first would be a good idea so the parser doesn't see the decimal first and have to worry about what follows being either a comment or a math operator.

yrinfish · « **Reply #213 on:** June 17, 2011, 12:37:09 pm »

decimal dot doesn't mean a comment if it's not the first token on the line.

and @scout, yes, that was intentional.

Munchor · « **Reply #214 on:** June 17, 2011, 12:38:26 pm »

Oh I forgot comments

@yrinfish: Well that seems right too.

Runer112 · « **Reply #215 on:** June 17, 2011, 12:39:27 pm »

Quote from: yrinfish on June 17, 2011, 12:37:09 pm

decimal dot doesn't mean a comment if it's not the first token on the line.

Actually the comment indicator works anywhere in a line. I don't think Quigibo intended for this originally, but I think having the side affect of inline comments is actually pretty nice.

yrinfish · « **Reply #216 on:** June 17, 2011, 12:42:40 pm »

Edit: It does? oh

Ok, scout thinks:

A./B Good idea
A./B Argh, comments
A./B Oh, that's true

lol

But I think that, while it is not really a good way when you want this:

Code: [Select]

:If H
: 35->A
:Else
: 10->A
:End
:./B->C

But, we'll see that later

Quigibo · « **Reply #217 on:** June 17, 2011, 05:14:30 pm »

eh.... as much as I like the dot, I would really like to avoid it so it doesn't look weird next to another new feature I'm adding.

Runer112 · « **Reply #218 on:** June 27, 2011, 03:31:09 pm »

Found some optimizations for p_IntSetup:

Code: (Original code: 45 bytes, a lot of cycles) [Select]

p_IntSetup:
	.db __IntEnd-p_IntSetup-1
	di
	ld	de,$8B01
	ld	a,d
	ld	i,a
	ld	a,l
	ld	hl,$8B00
	ld	b,e
	ld	c,l
	ld	(hl),$8A
	ldir

	and	%00000110
	out	(4),a
	ld	a,%00001000
	out	(3),a
	ld	a,%00001010
	out	(3),a

	ld	de,$8A8A
	ld	bc,__IntDataEnd-__IntData
	ld	hl,$0000
	ldir

	in	a,(6)
	ld	($8A8A+__IntDataSMC-__IntData+1),a
__IntEnd:
	.db rp_Ans,9

Code: (Optimized code: 42 bytes, a lot minus 5 cycles) [Select]

p_IntSetup:
	.db __IntEnd-p_IntSetup-1
	di
	ld	de,$8B01
	ld	a,d
	ld	i,a
	ld	a,l
	ld	hl,$8B00
	ld	b,e
	ld	c,l
	ld	(hl),$8A
	ldir

	and	%00000110
	out	(4),a
	ld	a,%00001000
	out	(3),a
	ld	a,(hl)
	out	(3),a

	ld	d,a
	ld	e,a
	ld	c,__IntDataEnd-__IntData
	ld	hl,$0000
	ldir

	in	a,(6)
	ld	($8A8A+__IntDataSMC-__IntData+1),a
__IntEnd:
	.db rp_Ans,9

Also don't forget the two interrupt optimizations that have been suggested earlier!

(removing di and removing port 6 SMC in programs)

Also, a bug report. After talking with thepenguin77 on IRC, I think I have confirmed my old belief that MemKit's Next() command has a bug regarding reaching the end of the VAT:

Quote from: Runer112 on February 15, 2011, 04:01:39 pm

Next(): 2 bytes and a few cycles saved. Also, isn't the end-of-VAT check in the wrong place? I could be wrong because my VAT experience isn't too great, but because this routine checks for the end of the VAT at the start, wouldn't this command advance the VAT pointer to the end of the VAT and not recognize it as the end until the next Next()? This would cause problems with programs reading garbage VAT data for the last "entry." If I'm right about this (which may not be the case), the third block of code I posted should hopefully recognize the end of the VAT as soon as it hits it and never advance the VAT pointer to point to the end.

Code: (Original code: 26 bytes, 152/66 cycles) [Select]
ld hl,(axv_X1t) ld de,($982E) or a sbc hl,de ret z add hl,de ld de,-6 add hl,de ld e,(hl) inc e xor a ld d,a sbc hl,de ld (axv_X1t),hl ret
Code: (Optimized code: 24 bytes, 144/66 cycles) [Select]
ld hl,(axv_X1t) ld de,($982E) or a sbc hl,de ret z add hl,de ld de,-6 add hl,de ld a,(hl) cpl ld e,a add hl,de ld (axv_X1t),hl ret
Code: (Optimized (and fixed?) code: 24 bytes, 144/113 cycles) [Select]
ld hl,(axv_X1t) ld de,-6 add hl,de ld a,(hl) cpl ld e,a add hl,de ld de,($982E) or a sbc hl,de ret z add hl,de ld (axv_X1t),hl ret

Runer112 · « **Reply #219 on:** June 30, 2011, 01:06:47 am »

A mix of a feature request and an optimization:

How about compound assignment operators (e.g. +=) for most Axe operations? They would offer savings on every operation that doesn't use a 2-byte variable at a constant address as the main operand. They could also offer even larger savings on basic operations like addition, subtraction, and bitwise logic.

Quigibo · « **Reply #220 on:** June 30, 2011, 03:01:03 am »

Those might get peephole optimized eventually, so I don't want to spend time on that feature right now. I realize now that a lot of optimizations I've already done could have been done via peepholes instead of special casing and it would have been a whole lot easier to code and more generalizable. I'm currently only doing the most conservative peephole ops right now and its already reducing all code by about 1-2% on average. I'm thinking I can get this to over 5% eventually, especially in code that is not already hyper optimized.

Also, I don't want to remove the port 6 stuff in because I think it potentially allows more advanced paging Axioms to use the regular interrupts. Plus it would be annoying to change.

Deep Toaster · « **Reply #221 on:** July 01, 2011, 12:39:04 pm »

Quote from: Runer112 on June 30, 2011, 01:06:47 am

A mix of a feature request and an optimization:

How about compound assignment operators (e.g. +=) for most Axe operations? They would offer savings on every operation that doesn't use a 2-byte variable at a constant address as the main operand. They could also offer even larger savings on basic operations like addition, subtraction, and bitwise logic.

I was just gonna post that in the other thread. Yes.

And I'm not good enough at ASM to give you any big suggestions, but here's another little request:
·EFF00
to LD L,0 and
·E00FF
to LD H,0. (The · dots are the 16-bit AND operator.)

EDIT: And
+EFF00
to LD H,255 and
+E00FF
to LD L,255.

Runer112 · « **Reply #222 on:** July 01, 2011, 06:49:17 pm »

That's been implemented since 0.5.2.

Deep Toaster · « **Reply #223 on:** July 03, 2011, 09:08:13 pm »

Time to update

Runer112 · « **Reply #224 on:** July 12, 2011, 01:05:00 am »

Wow, I just did something I didn't think was even possible. I found a good use for a forward djnz.

The following is the part of p_Disp4Lvl that initializes the mask:

Code: (17 bytes, ~62 cycles) [Select]

	ld	a,%11011011
	or	a
	ld	hl,flags+asm_flag2
	inc	(hl)
	jr	z,__Disp4Lvlskip
	rra
	ld	b,(hl)
	inc	b
	jr	z,__Disp4Lvlskip
	rra
	ld	(hl),-2

Code: (16 bytes, ~60 cycles) [Select]

	ld	a,%11011011
	or	a
	ld	hl,flags+asm_flag2
	inc	(hl)
	jr	z,__Disp4Lvlskip
	rra
	ld	b,(hl)
	djnz	__Disp4Lvlskip
	rra
	ld	(hl),-2

Author Topic: Assembly Programmers - Help Axe Optimize! (Read 156958 times)

yrinfish

Re: Assembly Programmers - Help Axe Optimize!

Munchor

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!

yrinfish

Re: Assembly Programmers - Help Axe Optimize!

Munchor

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!

yrinfish

Re: Assembly Programmers - Help Axe Optimize!

Quigibo

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!

Quigibo

Re: Assembly Programmers - Help Axe Optimize!

Deep Toaster

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!

Deep Toaster

Re: Assembly Programmers - Help Axe Optimize!

Runer112

Re: Assembly Programmers - Help Axe Optimize!