Truly shocking code (z80 asm)
Moderator: MaxCoderz Staff
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
It would seem so, yet many people have posted here
And of course it can be thought of as a warning to people who are learning asm: do not use "scf ccf" unless you absolutely need it, and that won't be often. If you need H to be set you could use AND A to reset the carry, and if you need H to be reset you could use OR A to reset the carry, and you can choose if you don't need H at all - as is the case with SBC.
And of course it can be thought of as a warning to people who are learning asm: do not use "scf ccf" unless you absolutely need it, and that won't be often. If you need H to be set you could use AND A to reset the carry, and if you need H to be reset you could use OR A to reset the carry, and you can choose if you don't need H at all - as is the case with SBC.
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
Well, you dont come across as evil ... just a little bit arrogant thats all.
I come across a lot of people who have a little programming experience under their belt where i study/work. Often, some of these people get a little ahead of themselves; they pick things up easily, develop and ego, and then think that they are quite a bit smarter than everyone else. Typically they will try to subtly prove this in ways ranging from making un-needed remarks about other peoples work, posting code that they are proud of in frequently accessed places, running programs or websites etc on machines and then walking away, that kind of stuff. That sort of behaviour kind of irks me since its not really beneficial to anyone. One of the big drawbacks is that these people generally dont develop into really great programmers because such a 'know-it-all' mentality makes them believe that they have very little to learn.
King Harold, im not saying that you are one of these people. Its just that some aspects of these threads remind me of people that i know who are like that. I am probably just reading things from a wong angle.
I come across a lot of people who have a little programming experience under their belt where i study/work. Often, some of these people get a little ahead of themselves; they pick things up easily, develop and ego, and then think that they are quite a bit smarter than everyone else. Typically they will try to subtly prove this in ways ranging from making un-needed remarks about other peoples work, posting code that they are proud of in frequently accessed places, running programs or websites etc on machines and then walking away, that kind of stuff. That sort of behaviour kind of irks me since its not really beneficial to anyone. One of the big drawbacks is that these people generally dont develop into really great programmers because such a 'know-it-all' mentality makes them believe that they have very little to learn.
King Harold, im not saying that you are one of these people. Its just that some aspects of these threads remind me of people that i know who are like that. I am probably just reading things from a wong angle.
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
It's a good thing I don't work then eh?
you know I've said that I sucked at coding more often than I said it about others though, you even told me not to do it (don't ask me where that was though, but I remember it)
But you know, I couldn't very well let someone get away with "scf ccf" now could I? (yea I suppose I could.. but still)
would it suffice if I'd say that I wouldn't have been able to write quicksort at all? I don't have a clue of how to implement it in asm..
(which I why I thought it odd that someone who does, does not seem to know the fastest way to reset the carry flag)
you know I've said that I sucked at coding more often than I said it about others though, you even told me not to do it (don't ask me where that was though, but I remember it)
But you know, I couldn't very well let someone get away with "scf ccf" now could I? (yea I suppose I could.. but still)
would it suffice if I'd say that I wouldn't have been able to write quicksort at all? I don't have a clue of how to implement it in asm..
(which I why I thought it odd that someone who does, does not seem to know the fastest way to reset the carry flag)
- tr1p1ea
- Maxcoderz Staff
- Posts: 4141
- Joined: Thu 16 Dec, 2004 10:06 pm
- Location: I cant seem to get out of this cryogenic chamber!
- Contact:
Well, i dont see why you cant let them get away with it? You will notice that EVERYONE else in this thread feels that it isnt even worth bringing up.
When you start knocking substantial cc's off routines, thats when you should bring it up. If you could optimise the quicksort routine by a bit, or a sprite routine or clipped line routine or something ... im sure there will be many grateful people .
When you start knocking substantial cc's off routines, thats when you should bring it up. If you could optimise the quicksort routine by a bit, or a sprite routine or clipped line routine or something ... im sure there will be many grateful people .
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
Without optimizing the entire routine but only taking in small blocks I made this (some months ago) it's far from perfect, but I think it's slightly better than Frank's:
I still don't have a clue how it works, but it works..
Be careful not to sort anything too large - it will corrupt the VAT through stackoverflow. The whole thing might be optimisable by swapping hte use of DE and BC but I'm not sure how usefull that would be
As far as 'worth bringing it up' goes: it was worth it to me, and I brought it up so.. So that's a matter of opinion
Code: Select all
qsort: .module Sort ;Input: BC = first element, DE = Last element (byte after end -1)
;Destroys: AF, BC, DE, HL
ld hl,0
push hl
quicksort:
-:
ld h,b
ld l,c
or a
sbc hl,de
jr c,{+} ;loop until lo<hi
pop bc
ld a,b
or c
ret z ;bottom of stack
pop de
jr {-}
+: push de
push bc
ld a,(bc)
ld h,a ;pivot
dec bc
inc de
fromleft: ;do i++ while cur<piv
inc bc
ld a,(bc)
cp h
jr c,fromleft
fromright: ;do i-- while cur>piv
dec de
ld a,(de)
ld l,a
ld a,h
cp l
jr c,fromright
push hl ;save pivot
ld h,d
ld l,e
or a
sbc hl,bc
jr c,{+} ;exit if lo>hi
ld a,(bc)
ld h,a
ld a,(de)
ld (bc),a
ld a,h
ld (de),a ;swap
pop hl ;restore pivot
jr fromleft
+:
pop hl ;restore pivot
pop hl ;pop lo
push bc ;stack=left-hi
ld b,h
ld c,l ;bc=lo,de=right
jr quicksort
.endmodule
Be careful not to sort anything too large - it will corrupt the VAT through stackoverflow. The whole thing might be optimisable by swapping hte use of DE and BC but I'm not sure how usefull that would be
As far as 'worth bringing it up' goes: it was worth it to me, and I brought it up so.. So that's a matter of opinion
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
You might want to look through Franks source, it's not just 3 lines of code that I'm complaining about, it's the use of "scf ccf" to reset the carry flag, and Frank ALWAYS does it like that - not just once (which would be forgivable)
Imo, it's comparable to the use of RLC A where you DON'T need to preserve some flags (in which case RLCA should be used of course)
Imo, it's comparable to the use of RLC A where you DON'T need to preserve some flags (in which case RLCA should be used of course)
Re: Truly shocking code (z80 asm)
frank is the one who wrote the quicksort King Harold was talking about.King Harold wrote:http://www.ticalc.org/archives/files/fi ... 34716.html
Frank Yaul (in "TI86 Z80 Quicksort Implementation") writes:Code: Select all
scf ccf sbc hl,de
someone who can write a Quicksort Implementation (which works, I've tested it) does not know the side effects of 8bit logic operations? Or does the 86's z80 work different?
In Memory of the Maxcoderz Trophy
The guy getting sandbagged.Jim e wrote:Who's frank?
SCF/CCF is perfectly understandable. It's the most intuitive method. It only affect one flag unlike xor A. And for anyone used to instruction sets that have CLC to CLear Carry (or similar), this would make perfect sense. The oneupmanship? Not so much.
My diet consists of nails, code-stealers, and HP fans.
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
Projects:
Robot War [TI-82, TI Flash App]
Sonic the Hedgehog [Multiplatform]
I think it's his way, and a pretty good way for that matter to learn from looking at other people's code. And besides, didn't CoBB just give him permission to look at the code? although he didn't specifically mention that King Harold could add it to this thread.tr1p1ea wrote:Why are you explictly looking for weird and strange code to go on about in the first place?
edit: perhaps next time you should
1.) Give the thread a nicer and less likely to offend name
2.) Put it in a less prominent (I mean it's not the first thing on the top of the page) thread like Programming Help
OR probably the least likely to offend if you are truly just asking a question
3.) Go onto IRC and discuss w/ people on #tcpa, #revsoft, #maxcoderz, #cemetech, #unitedti, #omnimaga, or the many other ti-calc related channels.
-
- Calc King
- Posts: 1513
- Joined: Sat 05 Aug, 2006 7:22 am
I never said one should use XOR A, it zero's A!DigiTan wrote:The guy getting sandbagged.Jim e wrote:Who's frank?
SCF/CCF is perfectly understandable. It's the most intuitive method. It only affect one flag unlike xor A. And for anyone used to instruction sets that have CLC to CLear Carry (or similar), this would make perfect sense. The oneupmanship? Not so much.
I said that, if you're going to SBC afterwards and thus do not need any flags beside the carry flag, one could aswell use AND A or OR A and I was kinda shocked that someone who can write quicksort did not know it was possible.
Evidently the guys at Intel (who later partly turned into ZiLOG) thought it unnecessary to add a CLC when they already had a OR A, the Carry flag probably doesn't have to be cleared without destroying other flags(other than H and N that will be killed anyway) that often anyway.
But ok, I'll try to be a little less offensive next time.