[meynaf]

I see things have advanced this week-end...

Originally Posted by Thorham

And if you don't have expensive instructions, it's better to forget about the whole i-cache and just rely on the algorithm's speed. Sometimes it just can't be helped. This was the case with the tokenizer, which I actually haven't re-written (for an experimental compiler, which I'm now just doing in C)

For a compiler, the tokenizer isn't really the time-critical part. I think the best practice is to simply make the code as small as possible.

Originally Posted by Thorham

Mis-interpreted that one, I was thinking something completely different

What were you thinking then ?

Originally Posted by Thorham

Browsers do use a lot of memory, so I do my browsing with the peecee, it's just more comfortable. Also the amiga os browsers I have seen (in the past), aren't up to the modern standards, I wonder if they are today. Wouldn't actually matter, as I don't have a network on my amiga right now (and the serial/parallel ports are a no go area, as they are a million times to slow).

Browsers on Amiga aren't up to the modern standards, so far not, although they're fast for what they do. But, no, I will not use my old 56k modem again if I can do otherwise

Originally Posted by Thorham

Well, I'm thinking about it. After seeing how fast and easy my current code makes viewing large images, I really should. It would actually be pretty crazy not to. I only have to get the grips with intuition coding, so it's not even an unrealistic thought.

If it would actually be pretty crazy not to do something, then don't do it.
(sorry I just couldn't resist )

As for intuition coding, everything is done within my library, I'll nevermore call OpenScreenTagList/OpenWindowTagList directly...
You can look at it, or, simpler, just use it. Opening an intuition screen is bloody easy.

Originally Posted by Thorham

The scale factors are handy, and I think the scaling is free of charge! While the 32bit mul/div opcodes are nice to have, they are slower then their 16bit equivalents. Sometimes they are useful, plain and simple. You know what it's like to have to make do without them:

But are the bitfield instructions handy ? (ok, bfffo saved me once, but...)
Are cas/cas2/chk2 really useful ?

Originally Posted by Thorham

Anyway, I hope you like the example bmp viewer, but I'm sure you'll agree it can be optimized, and written better in places... And of course, it's all in plain 68000

I'll do mine if I've got enough time. Making a bmp.s for my viewer is actually pretty easy : it needs only to check if the file format is a bmp, get the image dimensions, and feed the data "as is" to the rendering engine...

Originally Posted by Thorham

You could just have your own code handle the 16 byte alignment by simply copying the loop to a 16 byte aligned address. May require some fiddling, but should still work in a lot of cases. That way, your loop can be 256 bytes long.

I would personnally never do that. Looks like bad practice to me. Evil.


To Kalms : feel free to bite whenever you want.
You got it right with the burst stuff.
When it's inactive, we're fetching per 4 bytes.
When it's active, we're fetching per 16 bytes. Slower than one longword access, but faster than 4 times a longword access.
So it's good for consecutive memory accesses, e.g. for code or for a copymem. But I personnally leave it disabled for data, as it's better for everyday use.