Pointer type for ST video addresses?

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4852
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Pointer type for ST video addresses?

Postby simonsunnyboy » Mon Feb 08, 2016 5:02 pm

I have wondered for quite some time which datatype matches a generic address like the ST video memory or any virtual screen the best when using C99.

Due to the generic nature, void* seems most natural but that requires recasting when working with the pointer.
uint16_t* helps for indicating the bitplane nature but is awkward in other places.

The only thing I know is that I dislike using long/(u)int32_t for this.....

Any opinions for obtaining clear and cast-free code? Note that the pointer may be passed to assembly language routines aswell.
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 678
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Pointer type for ST video addresses?

Postby mfro » Mon Feb 08, 2016 5:57 pm

simonsunnyboy wrote:... Due to the generic nature, void* seems most natural but that requires recasting when working with the pointer...



a void* pointer cannot be dereferenced directly, that's true. But it can be directly assigned to any other pointer type.

Instead of

Code: Select all

void *screen_address;

* (uint16_t *) screen_address = xxx;


just do

Code: Select all

void *screen_address;
uint16_t *sc_word = screen_address;

sc_word[0] = xxx;


I find that much more readable and a good compiler will optimize away the superfluous pointer assignments anyway.

You just need to make sure you don't get caught by pointer aliasing (but you'll need to do that anyway).

User avatar
shoggoth
Nature
Nature
Posts: 853
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Pointer type for ST video addresses?

Postby shoggoth » Mon Feb 08, 2016 7:13 pm

union
{
void* blaha;
uint16_t* schproink;
intptr_t fap;
} screen;

EDIT: Actually, since I'm banging hardware, I'm doing:

union
{
uint8_t bytes[4];
void* adr;
} screen;
Ain't no space like PeP-space.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4852
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pointer type for ST video addresses?

Postby simonsunnyboy » Mon Feb 08, 2016 8:09 pm

Ahh, I clearly forgot about the union here. Too nice that pointers on the ST are always 32bit, regardless on what they are pointing to.
So it is really preferred to go the void* way and not the other way round.

I'm still willing to hear about more opinions :)
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
Mikefulton
Captain Atari
Captain Atari
Posts: 169
Joined: Sun Nov 29, 2015 10:27 am

Re: Pointer type for ST video address

Postby Mikefulton » Wed Feb 10, 2016 10:12 pm

shoggoth wrote:union
{
uint8_t bytes[4];
void* adr;
} screen;


Did you intend to do an array for 'bytes', or did you want to do a pointer to an array?

Frankly I think a uint16_t pointer is all you really need for manipulating bitplane-based buffers. For true color modes, TYPEDEF a pixel layout and use a pointer for that new type.

User avatar
shoggoth
Nature
Nature
Posts: 853
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Pointer type for ST video address

Postby shoggoth » Thu Feb 11, 2016 6:16 am

Mikefulton wrote:
shoggoth wrote:union
{
uint8_t bytes[4];
void* adr;
} screen;


Did you intend to do an array for 'bytes', or did you want to do a pointer to an array?


I think SimonSunnyBoy wanted a pointer to an array; I just gave an example of a useful type for screen address manipulation if you're banging the hardware directly. Obviously you could use shifts and stuff instead, it's a matter of taste I guess.
Ain't no space like PeP-space.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 678
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: Pointer type for ST video addresses?

Postby mfro » Thu Feb 11, 2016 8:36 am

Strictly speaking, the union approach is violating the C standard (although it usually works as intended).

The standard says that you are only allowed to read from one of the accessors if you've written through the same before. Writing through the void * pointer followed by a read through the "bytes" accessor is explicitely stated undefined behaviour (so your compiler is free to reboot your machine or release an H-bomb somewhere if it wants to).

Better not do that.

Also note that if you have interrupts modifying screen contents, you should define your screen memory volatile.

User avatar
shoggoth
Nature
Nature
Posts: 853
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Pointer type for ST video addresses?

Postby shoggoth » Thu Feb 11, 2016 11:08 am

mfro wrote:Strictly speaking, the union approach is violating the C standard (although it usually works as intended).

The standard says that you are only allowed to read from one of the accessors if you've written through the same before. Writing through the void * pointer followed by a read through the "bytes" accessor is explicitely stated undefined behaviour (so your compiler is free to reboot your machine or release an H-bomb somewhere if it wants to).

Better not do that.


Strictly speaking it's butt ugly in several ways, but since the usage scenario in this case is limited to the Atari 16/32 range I wouldn't care too much about that; it's highly unlikely to cause trouble. I've seen it fail on some awkward architectures and compilers though (HiTech C for some incarnation of the dreadful PIC iirc).
Ain't no space like PeP-space.

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4852
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pointer type for ST video addresses?

Postby simonsunnyboy » Thu Feb 11, 2016 5:24 pm

PIC is crap anyway ;)

On the m68k architecture where pointers are gracefully structured, always 32bit, I think it is a very readable way, esp. for the pesky register accesses shoggoth has in mind.

My own use case is actually less for the hardware banging itself but for accesses to draw data instead.
The basic question question is: is it nicer to have Screen_Clear(void * scr_ptr) or Screen_Clear(uint16_t * scr_ptr) as the bitplane access in the actual routine will really access bitplane words with 16bits each anyway.

Being overcorrect I might be tempted to use a bitplane_t aswell to make it really really readable. But is it worth as there is really just a single uint16_t word necessary?
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4852
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: Pointer type for ST video addresses?

Postby simonsunnyboy » Mon Feb 15, 2016 6:09 pm

*Moderator note: Topic splitted, please keep your discussion about implementation defined and undefined compiler behaviour in a seperate thread. This should keep the main topic "pointer for ST video memory"
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 2 guests