6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 1:40 am

All times are UTC




Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Wed Aug 28, 2024 11:59 am 
Offline
User avatar

Joined: Sun Nov 01, 2020 10:36 am
Posts: 37
Location: Tatooine
Code:
prrel:
    ; show the target address of a branch instruction
    ; we've already incremented PC past the operands
    ; so it is the baseline for the branch
    ; we have the offset in A, with sign in N, C=0
        php                     ; save sign of offset
        adc pc                  ; C already clear from #args check
        tay                     ; Y is LSB
        lda pc+1
;        bcc +
;        ina
;+
   adc #0     ; if C=0 then no change, if C=1 then it's like the INA

        plp
        bpl +
        dea
+


One whole byte less!...
at least you get to a round 500


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 28, 2024 1:21 pm 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 336
pdragon wrote:
if you use an an 8-bit analogue of the djb2 hash where you keep a running 'sum' k and for each character circular rotate k 5 bits left and then xor with the next character, you get a single byte key which is unique over these 70 three letter mnemonics.


Are you sure about that? I tried, and get collisions for a number of them (for example, $40 for LSR, PHA, and TXS).

Collisions are OK though. I experimented with a very simple 6502-friendly hash (shift current hash left one bit, xor next character, 128 entry table). If there's a collision while building the table I bump the existing item to the next slot. Lookups are done by comparing the string in each slot until it is either found or an empty slot is found. The worst case is INX, which hash a hash of $60 but ends up in slot $67. Items that aren't in the table can take a lot longer, but they're errors so their speed is less important.

This would help an assembler, not a disassembler, and it helps speed rather than size, so would perhaps be more suited to its own thread if anyone wants to continue.

That disassembler is incredible. The operand packing is particularly genius, and the code is surprisingly readable for something so intricate.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 28, 2024 4:47 pm 
Offline

Joined: Tue Sep 26, 2023 11:09 am
Posts: 109
yup, i think i messed up my hash test... the collision idea is nice tho. agree lets do a new thread if assembler idea gets traction


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 28, 2024 5:20 pm 
Offline

Joined: Tue Jul 30, 2024 6:20 pm
Posts: 73
There is a bunch of stuff out there about creating perfect hashes.

Also, the chess community has created some very interesting techniques for dealing with things like this...


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 29, 2024 1:29 am 
Offline

Joined: Mon Sep 17, 2018 2:39 am
Posts: 138
Hi!

enso1 wrote:
There is a bunch of stuff out there about creating perfect hashes.


But we don't want a perfect hash, we need collisions for all the bytes that map to the same opcode name - this is what makes finding the hash difficult :)

Have Fun!


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 29, 2024 10:43 am 
Offline

Joined: Tue Sep 26, 2023 11:09 am
Posts: 109
Another nice contribution from dmsc gets us to 500/560


Top
 Profile  
Reply with quote  
PostPosted: Thu Aug 29, 2024 2:26 pm 
Offline

Joined: Tue Jul 30, 2024 6:20 pm
Posts: 73
Maybe we can get billions of 6502 fans to do a distributed hash search on all those billions of 6502 devices WDC sold!


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 31, 2024 2:13 am 
Offline

Joined: Tue Sep 26, 2023 11:09 am
Posts: 109
Added a description of dmsc's nice indexing and data overlap strategy so I'd understand it next time I looked at it, and got dragged in to another game of data tetris myself. Ridiculous cost/benefit to save 3 bytes. But now 497/557. Here's a snippet from the comments:

Code:
The data layout is quite intricate to create some areas where
different data structures overlap to save space.  Here's a rough sketch:

+------------------+
|   slice masks    |
|   16-18 bytes    |
+------------------+

+------------------+-----------------+----------------------------+
| mnemonics 0..$40 |   (other data)  | spc mnemonics $44..$4c/$50 |
|     64 bytes     |     8 bytes     |        16 - 24 bytes       |
+------------------+-----------------+----------------------------+
                  /                   \
                 +---------------------+
                 |  operand template   |
                 |   8 byte string     |
                 +---------------------+

+-------------------+-----------------------+---------------------+
|  mode tbl 0..$20  |      (other data)     |  spc modes $7f-$7f  |
|   16 bytes        |        42 bytes       |      6 bytes        |
+-------------------+-----------------------+---------------------+
                   /                         \
                /    8 + 12 + 15 + 15           \
             /              - 1 - 5 - 2            \
          /                     = 42 bytes            \
        +---------+                                     |
        | formats |  1 byte overlap                     |
        | 8 bytes | /                                   |
        +-------+-+-------------+                       |
                | spc mode opcs |  5 byte overlap       |
                |   12 bytes    | /                     |
                +---------+-----+---------+             |
                          | spc mnem opcs |  2 byte overlap
                          |   15 bytes    | /           |
                          +-----------+---+-------------+
                                      |  spc mnem idxs  |
                                      |     15 bytes    |
                                      +-----------------+



Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 31, 2024 7:15 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Very nice! Thanks for sharing.


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 31, 2024 9:47 am 
Offline

Joined: Tue Sep 26, 2023 11:09 am
Posts: 109
Lovely simplification from dmsc to get rid of two more loop index checks. Reversed one and realized only parity matters in another.
Also spotted that sta adr,y is 3 bytes vs 2 for sta adr,x for zp address since it has no short mode. I had to compare assembly listings to see where that extra byte had gone!

Now 492/552.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 32 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: