 |
Welcome to the Natami / Amiga ForumThis forum is for AMIGA fans interested in the new NATAMI platform.
Please read the forum usage manual.
|
 Welcome to the Natami lounge.
Meet new AMIGA friends here and enjoy having a friendly chit chat. |
| Amiga's Bottlenecks | page 1 2 3 4
|
|---|
|
|---|
Matt Hey
USA
| |
Posts 733
23 Oct 2010 05:51
| Thomas Richter wrote:
|
*Sigh* Except that I'm not operating on a bit field. This is not the case. I'm writing a continuous stream of bits and try to insert variable-length bit fields into that stream. |
Please be open minded. Bits are the most basic data elements of a computer. Bit fields are a series of at least 1 bit. Therefore, everything in a computer is a bit field.
Thomas Richter wrote:
|
Matt Hey wrote:
|
I interpret this from "If less bits are available in a0 than in the bit-field, load only the available bits."
|
a0 is the target of the operation, not the source. And it contains bits in groups of eight, octets, or bytes as they are usually called.
|
Perhaps you have been away from the 68k for too long. Let me give you a refresher. On the 68k, instructions are formatted like this...
instruction.size source,destination
Bit fields are no exception. So bfins is formatted like...
bfins sourceDn,destinationEA{offset:width}
That is, the source Dn is inserted into the destination EA bit field starting at offset bit for width number of bits. When using bfextu or bfexts, the bit field is the source as these are the opposite operation. Understand?
Thomas Richter wrote:
|
Matt Hey wrote:
|
Now let's look at your bfinc (a0),d0{d1:d2}. I believe this should be bfinc d0,(a0){d1:d2} as the bit field base is (a0). There seems to be an implicit 5th variable that specifies a maximum size.
|
No. There is no maximum size. It should insert bits d0 into a stream pointed to by a0, starting from bit d1, insert *at most* d2 bits, then increment d1 by the inserted bits, and return indicating whether all or only some bits were inserted. Then I can increment a0 (or write the written byte) or test that byte for 0xff.
|
Of course there is an implicit maximum size past which no bits are written. From reading your new post, the maximum size is the end of the byte. That's where you want to stop writing any more bits and test the last byte. The new addressing mode I came up with for bit fields is flexible enough to work with the JPEG encoder just as I described. Here is what it looks like as applied to this particular problem...
.next_byte_loop:
lea (1,a0),a1 ;reference bit field from end
moveq #-8,d1 ;bit field starting offset in bits
.fill_byte_loop:
...
move.l bits,d0
move.l bitsize,d2
...
bfins d0,(a1){d1+d2}
bcc .fill_byte_loop ;carry set when offset is no longer negative
cmp.b #$ff,(a0)+
bne .next_byte_loop
clr.b (a0)+
...
bra .next_byte_loop
It's necessary for the offset to count down to 0 so that a 5th variable is not introduced and a compare used. Efficient loops using a counter count down to 0 for the same reason. If we start at the beginning with a positive offset and count down, then we deal with the bits as a stack instead of as a queue. Maybe this is too complicated for programmers? For comparison, we will look at the approximate method without the new mode used by bfins...
.next_byte_loop:
lea (1,a0),a1 ;reference bit field from end
moveq #-8,d1 ;bit field starting offset in bits
.fill_byte_loop:
...
move.l bits,d0
move.l bitsize,d2
...
move.l d1,d3
add.l d2,d3 ;calculate the offset after bfins
bgt .no_fit
bfins d0,(a1){d1:d2}
move.l d3,d1
bne .fill_byte_loop
.byte_full:
cmp.b #$ff,(a0)+
bne .next_byte_loop
clr.b (a0)+
...
bra .next_byte_loop
.no_fit:
lsr.l d3,d0 ;shift out unwanted bits
sub.l d3,d2 ;reduce width to new number of bits
bfins d0,(a1){d1:d2}
add.l d2,d1 ;offset should be d1=0
bra .byte_full
There is another possibility if the bits inserted are never more than 24 bits in width. In this case, a temporary register could be used to insert the bits into the upper byte. We then rotate the upper byte to the normal byte position when it is full and move it to memory. The bit field instructions do wrap around when used to a register or this method would solve the problem of creating a barrier. Bit 32 maps to 0, bit 33 maps to 1, etc...
moveq #8,d1
.next_byte_loop:
subq.l #8,d1 ;bit field starting offset - byte inserted
.fill_byte_loop:
...
move.l bits,d0
move.l bitsize,d1
...
bfins d0,d3{d1:d2}
add.l d2,d1
cmp.l #7,d1
blt .fill_byte_loop
rol.l #8,d3
move.b d3,(a0)+
cmp.b #$ff,d3
bne .next_byte_loop
clr.b (a0)+
...
bra .next_byte_loop
I hope I'm a little closer with this example code. There is still parts I don't understand though.
Thomas Richter wrote:
|
Then I'm faster with shifting and masking. I can do that ok right now. I don't need a bitfield instruction. If I need to code a compare there for every field of bits I insert, I'm faster doing the shifting and masking manually. I don't need a bitfield-compare. It is useless. I need to compare a *byte* at a *byte offset*. Not a bitfield entry.
|
A mask and shift technique would still probably be fastest on the 68060 with it's slow bit field instructions. Having fast bit field instructions does make programming easier.
Thomas Richter wrote:
|
I guess concrete code would help. Unfortunately, the forum chokes on any shift operator I post here...
|
The forum has messed up a few of my posts too but at least it doesn't choke on the assembler shift instruction ;).
| |
Matt Hey
USA
| |
Posts 733
23 Oct 2010 23:46
| I think the last idea for a new bit field mode is too complicated for the masses and not the easiest to implement. I propose a new idea. I will call them bit registers. Bit registers would be very much like bit fields except that they only operate in registers. Oh great, something new to learn, right? No, something old and familiar to use ;). The bit registers would use the same numbering system for bits as the bit manipulation instructions like btst, bset, bclr and bchg and the common Motorola bit numbering system. That is, the least significant bit is bit 0 and the most significant bit for 32 bits is 31. Now we create variations of all the old bit field instructions with all offsets and offset results using the old numbering system. All bits written outside of bits 0-31 will be discarded. The carry flag could be set if bits less than 0 are read or written and the overflow flag if bits greater than 31 are read or written. This gives a barrier/protection for algorithms that write outside of the register. The new instructions would be... brchg Dn{offset:width}
brclr Dn{offset:width}
brexts Dn{offset:width},Dn
brextu Dn{offset:width},Dn
brffo Dn{offset:width},Dn
If no bit in the bit field is set to one, the value in Dn
is the field offset MINUS the field width.
brins Dn,Dn{offset:width}
brset Dn{offset:width}
brtst Dn{offset:width} The instructions could use the same encodings as the bit field instructions but using an unused EA. The instructions should be easy to implement as they are only slight variations of the regular bit field instructions. They should be fast (1 cycle) as they are register only. It's very handy to be able to refer to the bits in either bit numbering system. The barrier is an advantage over wrapping as well. I like to kill 2 birds with 1 stone :). I very much like this idea. It's general purpose, easy to use and fast. Look at what it does for the JPEG encoding example... .next_byte_loop:
moveq #7,d1 ;bit register starting offset
.fill_byte_loop:
...
move.l bits,d0
move.l bitsize,d2
...
brins d0,d3{d1:d2}
sub.l d2,d1
bpl .fill_byte_loop
move.b d3,(a0)+
cmp.b #$ff,d3
bne .next_byte_loop
clr.b (a0)+
...
bra .next_byte_loop I would use this. Would anyone else? Anybody like the idea? Does anyone see any disadvantages?
| |
Phil "meynaf" G.
France
| | (Natami Team)
Posts 393
25 Oct 2010 11:43
| Matt Hey wrote:
|
I would use this. Would anyone else? Anybody like the idea? Does anyone see any disadvantages?
|
I can say i like the idea. Actual bit-field ops are practical for memory, but not for registers where you often need the original bit-counting method and end up not using the bf because shift-and-mask becomes faster.I do not know how easy (or not) they are to do in HW.
But from an encoding POV they're easy to do :
11101xxx 11**ea** Dreg101o oo100lll
where :
. xxx is operation (bfextu, bfexts, bfins, etc)
. **ea** is 6-bit ea field, targeting a single longword
. D is D/A bit on 020 ext modes ; unused here (for now)
. ooo is offset reg
. lll is length reg
| |
Cesare Di Mauro
Italy
| |
Posts 526
25 Oct 2010 20:05
| Richard Maudsley wrote:
|
Cesare Di Mauro wrote:
|
Richard Maudsley wrote:
|
Maybe multiuser can be implamented similar to what win9x (or OS 9) had.
A program in startup sequence that you use to log in, then assigns folders for each user,moves files like user-startup and prefs, etc...
Obviously nearly no security, but would give the illusion of multiple users to the users, and still be compatable with all software. |
You don't need such trick.
MultiUserFileSystem worked and works quite well: EXTERNAL LINK ;)
|
Looks more like a trick than my approach :p |
I don't see the "trick". :P
| Besides, changing file system will no doubt cause problems somewhere. |
muFS is FFS-based. It uses just some unused space on FFS structure to store its metadata, leaving everything the same.At any time you can switch from FFS to muFS and viceversa, and I never had a single problem with any application using it. ;)
| |
Matt Hey
USA
| |
Posts 733
26 Oct 2010 02:02
| Phil G. wrote:
|
I can say i like the idea. Actual bit-field ops are practical for memory, but not for registers where you often need the original bit-counting method and end up not using the bf because shift-and-mask becomes faster.
|
Yep. The original Motorola numbering system works well for registers but not so well for memory and vise verse. Here is a real world example of finding the power of 2 of a texture size. For example, 256x256 textures need to be encoded as 8x8. Only texture sizes that are a power of 2 are valid. bfffo d0{0,32},d1
moveq #31,d0
sub.l d1,d0 vs brffo d0{31,32},d0
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
26 Oct 2010 06:22
| Cesare i would nearly ask for a BeFS port if it could help...
(BeFS holds meta data in a manner one would manage a DB)
| |
Cesare Di Mauro
Italy
| |
Posts 526
26 Oct 2010 07:21
| I know BeOS, but porting a filesystem from a POSIX-compliant implementation to AmigaOS is a BIG burden.
| |
Megol .
| |
Posts 675
27 Oct 2010 16:07
| Cesare Di Mauro wrote:
|
I know BeOS, but porting a filesystem from a POSIX-compliant implementation to AmigaOS is a BIG burden.
|
Yes but BeFS is well documented and not too complicated compared to other alternatives. AFAICR AROS developed the handling of filesystems compared to AmigaOS, maybe it would be easier to port by reusing AROS code (wild speculation)?
| |
Cesare Di Mauro
Italy
| |
Posts 526
28 Oct 2010 03:36
| Megol . wrote:
| | Yes but BeFS is well documented and not too complicated compared to other alternatives. |
Yes, it has a very well written book. :)
| AFAICR AROS developed the handling of filesystems compared to AmigaOS, maybe it would be easier to port by reusing AROS code (wild speculation)? |
I don't know how AROS works, so I can't answer.But due to its active development (especially this days, with the 68K branch), it's where we have to look at, for sure.
| |
Marcel Verdaasdonk
Netherlands
| |
Posts 3976
04 Jul 2012 19:56
| Necro on this thread on the end of the book there are links that i recently used the creator has given them away for free for none commercial use IIRC.
This could be used along the source of AROS to port BeFS to AMIGA systems.
| |
|
|
|
|
