arm-elf-gcc : change default data alignement depending on ARM/THUMB

arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Vincent Rubiolo]

Dear all,

I am trying to figure out why gcc always aligns on 4 bytes boundaries (32 bits) 
on arm-elf-gcc in an attempt to reduce code footprint. I found that GCC produces 
much bigger code than ADS (30 to 50 %) when ARM and THUMB are mixed 
(interworking enabled) on our project.

It indeed seems that ARM ADS 1.2 aligns on halfwords (16 bits) when in THUMB 
mode (along with much more sophisticated rules). GCC different behavior causes 
much more padding to be inserted in structs members and, as the project I work 
on uses HW mapped registers, application crashes.
For now, I worked around that using a compile time define to enable the 
__attribute((packed))__ on the struct(s). I would nevertheless like to know 
whether there is another solution.

I am also digging into the arm.h and arm.c files (thanks to the gcc's internal 
manual) to try to change the alignment behavior.

Could you give me other ideas/solutions on that point?

Thanks for your consideration,

Vincent

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Richard Earnshaw]

> Dear all,
> 
> I am trying to figure out why gcc always aligns on 4 bytes boundaries (32 bits) 
> on arm-elf-gcc in an attempt to reduce code footprint. I found that GCC produces 
> much bigger code than ADS (30 to 50 %) when ARM and THUMB are mixed 
> (interworking enabled) on our project.
> 
> It indeed seems that ARM ADS 1.2 aligns on halfwords (16 bits) when in THUMB 
> mode (along with much more sophisticated rules). GCC different behavior causes 
> much more padding to be inserted in structs members and, as the project I work 
> on uses HW mapped registers, application crashes.
> For now, I worked around that using a compile time define to enable the 
> __attribute((packed))__ on the struct(s). I would nevertheless like to know 
> whether there is another solution.
> 
> I am also digging into the arm.h and arm.c files (thanks to the gcc's internal 
> manual) to try to change the alignment behavior.
> 
> Could you give me other ideas/solutions on that point?
> 

GCC defaults to the old APCS rules on structure alignment and padding, 
which means that all structures are word-aligned by default.  ARM ADS uses 
the ATPCS rules where structures take the alignment of their most aligned 
member.

You can change gcc's default for this with the compiler switch

	-mstructure-size-boundary=8

but beware that this changes the ABI, so you will need to rebuild all your 
code (including the libraries) with this option.

R.

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff]

Vincent:


> It indeed seems that ARM ADS 1.2 aligns on halfwords (16 bits) when in 
> THUMB mode (along with much more sophisticated rules). GCC different 
> behavior causes much more padding to be inserted in structs members 
> and, as the project I work on uses HW mapped registers, application 
> crashes.
> For now, I worked around that using a compile time define to enable 
> the __attribute((packed))__ on the struct(s). I would nevertheless 
> like to know whether there is another solution. 


Avoid using structures for hardware i/o.  Seriously.

There are only minimal guarantees in ANSI regarding structure layout, 
not nearly enough to make them good for associating reliably with 
hardware.  As you've seen, structure implementations can change in 
response to changes in compiler settings and versions--- but the 
hardware doesn't!

The "packed" attribute helps a lot, but really only provides a 
suggestion to the compiler--- and hence, the compiler is free to ignore 
you if it wants to.  Alas, C doesn't provide a bulletproof way to do 
hardware i/o with an abstract data type.

This is all especially the case with bitmapped fields.  DON'T do 
bitmapped fields for hardware i/o, especially in cases where the 
register has "reserved, set to zero" bits!

Here's an example of why.  I was working some time ago on a DMA 
controller inside the Hitachi SH7045 (or maybe it was one of the other 
peripherals, I can't really remember now).  Anyway, a particular control 
register had some reserved bits in them, and the datasheet clearly 
stated that you _had_ to write zeros to those bits any time you touched 
the register.

Well, I thought I was being clever, and came up with a data structure 
that looked something like this (from memory):

   typedef struct {
   ...
      unsigned int rq1f3: 1;
      unsigned int reserved: 29;
      unsigned int r1f4: 2;
   ...
   } the_register_s;

This structure allows you to set the rq1f3 and r1f4 bits, but doesn't 
tell the compiler anything about the reserved bits.  As a result, when I 
did this:

   the_register_s *r = (the_register_s*)THE_REGISTER_ADDRESS;
   r->rq1f3 = 1;
   r->r1f4 = 2;

When I looked at the assembly code, I found that the compiler was doing 
basically this:

  *r |= 0x80000000;
  *r |= 0x00000002;

Which appears to be exactly what I was asking for.

BUT, see the problem?  I didn't either--- at first.  The reserved bits 
in this register sometimes read back nonzero data, and that data gets 
written back to the register due to the read-modify-write operation 
implemented by the compiler.  In violation of the instructions in the 
datasheet.  Net result was the CPU going into undocumented test modes 
that made it do strange things, including locking up at unpredictable 
times thereafter.

ANY time I've tried to be clever with data structures for hardware i/o, 
I've lived to regret it.

Oh, and I left the "volatile" keyword out of all of the above, but you 
absolutely, positively need it as well when you're touching hardware.  
If you don't believe me, turn on -O2 and see what happens.  :^)  Where 
the keyword goes in the above example is an exercise left to the 
reader.  :^)


Regards,


b.g.
--
Bill Gatliff
Embedded systems training and consulting
bgat@billgatliff.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Yves Rutschle]

On Thu, Aug 21, 2003 at 09:48:47AM -0500, Bill Gatliff
wrote:
> As you've seen, structure implementations can change in
> response to changes in compiler settings and versions---
> but the hardware doesn't!

Hey. Get your hardware developer to make hardware that can
read the software's mind as it should. :-)

> Oh, and I left the "volatile" keyword out of all of the above, but you 
> absolutely, positively need it as well when you're touching hardware.  

Linus Torvalds said somewhere he didn't like volatile
because it never did what people expected. Linux people
usually use a macro as follows:

#define barrier()   __asm__ __volatile__("": : :"memory")

which invalidates all assumption on memory: it forces things
to be pushed to the hardware.

E.g:

    int i;
    i = 0;
    i = 5;

will typically compile as one memory set (and if i is used
a few lines later, no memory access at all), whereas:

    int i;
    i = 0;
    barrier();
    i = 5;

will perform garantee a write instruction will be issued
(then you hope someone switched off the cache, but that's
another story entirely).

/Y

-- 
This signature left empty.

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff]

Yves:


>Hey. Get your hardware developer to make hardware that can
>read the software's mind as it should. :-)
>

:^)

>>Oh, and I left the "volatile" keyword out of all of the above, but you 
>>absolutely, positively need it as well when you're touching hardware.  
>>    
>>
>
>Linus Torvalds said somewhere he didn't like volatile
>because it never did what people expected. Linux people
>usually use a macro as follows:
>
>#define barrier()   __asm__ __volatile__("": : :"memory")
>  
>

I don't see why Linus (or anyone else, for that matter) would have a 
problem understanding how "volatile" works.

His approach is clearly one solution, albeit one that requires code like 
this:

int *reg = ADDR;

*reg = val1;
barrier();
*reg = val2;
barrier();
*reg = val3;
barrier();

Forget one of those barrier()'s, and you've given the optimizer a 
free-for-all (and yourself a real headache).  The more correct way:

volatile int *reg = ADDR;

*reg = val1;
*reg = val2;
*reg = val3;

The behavior of Linus's barrier() is implied by the "volatile" keyword.  
One less line of code to deal with, which doesn't sound like a big deal 
until you're an ADHD trying to maintain mutliple, 400K+ line code sets 
yourself.  :^)

Or, even better:

typedef volatile unsigned int *hwio32u;

hwio32u reg = (unsigned int*)0xfe;
*reg = 1;
*reg = 2;

Want proof?  :^)  With the volatile keyword in the typedef:

$ arm-elf-gcc -g -O3 -S test.c && less test.s
foo:
        /* load register address */
        mov     r0, #254 /* 0xfe */
        mov     r1, #1
        mov     r2, #2
        /* load write a '1' to it */
        str     r1, [r0, #0]
        /* load write a '2' to it */
        str     r2, [r0, #0]
        mov     pc, lr

Without:

foo:
        mov     r1, #2
        mov     r0, #254
        str     r1, [r0, #0]
        mov     pc, lr

The compiler optimizes away the first write to the register, which is 
exactly what you would want it to do if it weren't pointing to real 
hardware...

Oh, and Linus's approach ties you inextricably to gcc.  Mine works for 
any ANSI-compliant compiler.


b.g.

-- 
Bill Gatliff
Embedded Linux development and training services.
bgat@billgatliff.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Yves Rutschle]

On Thu, Aug 21, 2003 at 10:57:31AM -0500, Bill Gatliff wrote:
> I don't see why Linus (or anyone else, for that matter) would have a 
> problem understanding how "volatile" works.

I have a vague feeling that there used to be border cases
for which gcc happened to produced bad code. Either way, a
quick search brought me to this post which explains it quite
clearly (I think):

http://www.geocrawler.com/archives/3/597/2001/7/0/6253709/

Essentially, his appraoach allows to control where writing
back to memory is relevant and where it isn't, while
volatile forces it all the time.

It occurs to me that the comment is mostly targeted at
shared memory structures (shared between several processors,
that is), and probably much less relevant to actual hardware
accesses.
 
> The behavior of Linus's barrier() is implied by the "volatile" keyword.  
> One less line of code to deal with, which doesn't sound like a big deal 
> until you're an ADHD trying to maintain mutliple, 400K+ line code sets 
> yourself.  :^)

Well, Linus has an infinite number of monkeys checking code :)

> Oh, and Linus's approach ties you inextricably to gcc.  Mine works for 
> any ANSI-compliant compiler.

Yes. Linux is really only target at GCC. Oh, and this is the
x-gcc mailing list! :)

/Y
 
-- 
This signature left empty.

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff]

Yves:


>On Thu, Aug 21, 2003 at 10:57:31AM -0500, Bill Gatliff wrote:
>  
>
>>I don't see why Linus (or anyone else, for that matter) would have a 
>>problem understanding how "volatile" works.
>>    
>>
>
>I have a vague feeling that there used to be border cases
>for which gcc happened to produced bad code.
>

Perhaps, although I'm struggling to find any examples lately!

>Either way, a quick search brought me to this post which explains it quite
>clearly (I think):
>
>http://www.geocrawler.com/archives/3/597/2001/7/0/6253709/
>  
>
>Essentially, his appraoach allows to control where writing
>back to memory is relevant and where it isn't, while
>volatile forces it all the time.
>

Right, that's my read of his email too.  Which is another beef of mine 
with his code (ot): he refuses to ever let the compiler do the work for 
him. Yes, he gets a modest performance improvement by taking on 
volatility and several similar burdens (macros vs. inlines, typedefs, 
enumerations, etc.) himself, in exchange for a monumental maintenance 
headache.  Of course, he has a monumental staff...

But that's still no excuse.  If they weren't tracking down petty issues 
like barriers, endianness, etc., imagine what the core Linux developers 
could be working on!  Speaking hypothetically, of course: I have no idea 
what the daily life of a Linux kernel developer is like.  I just take 
what they give me and port it over, warts and all.

>>Oh, and Linus's approach ties you inextricably to gcc.  Mine works for 
>>any ANSI-compliant compiler.
>>    
>>
>
>Yes. Linux is really only target at GCC. Oh, and this is the
>x-gcc mailing list! :)
>

But had he started out with MSFT or Intel's tools instead, and used 
whatever facilities those tools provided him to implement his barriers, 
he'd be stuck there.  I avoid suggesting non-ANSI solutions to problems 
like this for a number of reasons, not the least of which is that it 
makes it easier to convert someone over to gcc down the road.  :^)


b.g.

-- 
Bill Gatliff
In the dark on embedded GNU?  Step into the light.
bgat@billgatliff.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Vincent Rubiolo]

Thank you Richard, Bill and Yves for your replies,

More info about on what I want to achieve : the conversion of our project from 
ADS 1.2 to the GNU toolchain. The project uses some code which is provided by 
another company for hardware interfaces along our own code.

As of today, the conversion seems fine. Files were adapted and the global 
behaviour is acceptable (some regression tests still failing though).

Richard :
The --mstructure-size=8 option helped gaining little space. Quoting from ADS 1.2 
manual, the alignment rules are much more complex than those of gcc for 
structures _members_ :

Field alignment
Structures are arranged with the first-named component at the lowest address. 
Fields are aligned as follows:
·A field with a char type is aligned to the next available byte.
·A field with a short type is aligned to the next even-addressed byte.
·Bitfield alignment depends on how the bitfield is declared. See Bitfields in 
packed structures for more information.
·All other types are aligned on word boundaries.

So we may run into problems with others structs (see end of post for expl of 
problematic struct).


Bill and Yves :
The padding problem came of the following struct declarations :

typedef struct
{
... (16 bits members)
   unsigned short int Bob;
   struct2 Jane;
... (other stuff)
} struct1;

where struct2 is the following :

typedef struct
{
    unsigned char   A[11];
    unsigned char   Reserved;
} struct2;

With ADS, Bob is aligned on a 16 bits boundary and Jane begins just after so 
everything is fine. With gcc, padding is inserted after Bob to reach a 32bit 
boundary hence system crashes because these structures are HW mapped. The packed 
attribute solved the issue for that struct.

Behind my question was the issue of code footprint.
I have found that the GNU toolchain produces code which is 30 to 50% bigger than 
the one of ADS, especially when debugging info is turned off. As I stated 
before, the project uses mixed ARM and THUMB code, so interworking is in the 
brawl. I am trying to figure, with the help of the binutils, why does gcc 
produces such big code.

We have two memory zones, RAM (little code, mainly data) and FLASH (code).
If debugging information is not enabled, ADS outstands GNU by 63% on FLASH and 
12% in RAM (optimised for size on both).
If debugging is enabled, the difference falls to 13 and 10% (still optimised or 
size for gcc, no optimisations for ADS).

I am still investigating and trying to find ways to reduce the footprint.

Thank you again for your consideration.

Regards,

Vincent

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Dan Kegel]

Vincent Rubiolo wrote:
> I am still investigating and trying to find ways to reduce the footprint.

Be sure to try strip on your binaries; on sh4, at least,
it makes a huge difference in binary size (though not in
code size).
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff]

Vincent:


Gcc's unoptimized code is extremely bloated, but I don't have a problem 
with that.  I think it's set up that way to make debugging easier, or 
something to do with compiler backends, or something (remember, I'm not 
on the gcc team!).  So the fact that gcc's unoptimized output is larger 
than anyone else's is neither surprising, or discouraging.  At least to me.

With optimizations turned on, however, I've seen gcc really close the 
gap with ADS since the 2.95.x days.  I haven't done any formal 
comparisons, but I haven't seen any heinous output from gcc, either.  
I'll be very interested to find out where the size difference is coming 
from.

One potential source is runtime libraries.  ADS's library structure is 
pretty granular, and their linker seems to be pretty good at discarding 
unused code.  GNU-compatible runtime libraries don't seem to be as 
fine-grained in their implementation as ADS, so the GNU linker isn't as 
helpful at keeping unused modules and/or functions out of the resulting 
image.  Or maybe it's because the GNU linker is more simplistic, and the 
library architecture isn't the source of the bloat.  Dunno.

At any rate, I've seen this contribute to size differences from time to 
time, although the difference was usually small for real-world 
programs.  The difference is frequently huge for "hello, world!", 
however, mostly because the bulk of that application *is* the runtime 
library.  That isn't realistic, and so I don't use hello-world as a 
benchmark for anything except the ability to get a clean link.  :^)


b.g.



Vincent Rubiolo wrote:

> Thank you Richard, Bill and Yves for your replies,
>
> More info about on what I want to achieve : the conversion of our 
> project from ADS 1.2 to the GNU toolchain. The project uses some code 
> which is provided by another company for hardware interfaces along our 
> own code.
>
> As of today, the conversion seems fine. Files were adapted and the 
> global behaviour is acceptable (some regression tests still failing 
> though).
>
> Richard :
> The --mstructure-size=8 option helped gaining little space. Quoting 
> from ADS 1.2 manual, the alignment rules are much more complex than 
> those of gcc for structures _members_ :
>
> Field alignment
> Structures are arranged with the first-named component at the lowest 
> address. Fields are aligned as follows:
> ·A field with a char type is aligned to the next available byte.
> ·A field with a short type is aligned to the next even-addressed byte.
> ·Bitfield alignment depends on how the bitfield is declared. See 
> Bitfields in packed structures for more information.
> ·All other types are aligned on word boundaries.
>
> So we may run into problems with others structs (see end of post for 
> expl of problematic struct).
>
>
> Bill and Yves :
> The padding problem came of the following struct declarations :
>
> typedef struct
> {
> ... (16 bits members)
>   unsigned short int Bob;
>   struct2 Jane;
> ... (other stuff)
> } struct1;
>
> where struct2 is the following :
>
> typedef struct
> {
>    unsigned char   A[11];
>    unsigned char   Reserved;
> } struct2;
>
> With ADS, Bob is aligned on a 16 bits boundary and Jane begins just 
> after so everything is fine. With gcc, padding is inserted after Bob 
> to reach a 32bit boundary hence system crashes because these 
> structures are HW mapped. The packed attribute solved the issue for 
> that struct.
>
> Behind my question was the issue of code footprint.
> I have found that the GNU toolchain produces code which is 30 to 50% 
> bigger than the one of ADS, especially when debugging info is turned 
> off. As I stated before, the project uses mixed ARM and THUMB code, so 
> interworking is in the brawl. I am trying to figure, with the help of 
> the binutils, why does gcc produces such big code.
>
> We have two memory zones, RAM (little code, mainly data) and FLASH 
> (code).
> If debugging information is not enabled, ADS outstands GNU by 63% on 
> FLASH and 12% in RAM (optimised for size on both).
> If debugging is enabled, the difference falls to 13 and 10% (still 
> optimised or size for gcc, no optimisations for ADS).
>
> I am still investigating and trying to find ways to reduce the footprint.
>
> Thank you again for your consideration.
>
> Regards,
>
> Vincent
>
>
>
>

-- 
Bill Gatliff
Linux, NetBSD, RTEMS, eCos: yea, I do free software!
bgat@billgatliff.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Bill Gatliff]

Dan et al:


Aah, good point.  Use the 'size' utility, i.e. arm-elf-size, for 
apples-to-apples comparisons.  Debugging info is huge in an ELF file, 
but contributes exactly zero bytes to the runtime footprint.


b.g.


Dan Kegel wrote:

> Vincent Rubiolo wrote:
>
>> I am still investigating and trying to find ways to reduce the 
>> footprint.
>
>
> Be sure to try strip on your binaries; on sh4, at least,
> it makes a huge difference in binary size (though not in
> code size).
> - Dan
>

-- 
Bill Gatliff
Embedded Linux development and training services.
bgat@billgatliff.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Grant Edwards]

On Fri, Aug 22, 2003 at 01:12:52PM -0500, Bill Gatliff wrote:

> With optimizations turned on, however, I've seen gcc really close the 
> gap with ADS since the 2.95.x days.  I haven't done any formal 
> comparisons, but I haven't seen any heinous output from gcc, either.

I've recently compared size/performance of an eCos application
built w/ 2.95.x and with 3.2.x, and I've seen a size reduction
of about 20% or so, along with a corresponding increase in
performance.

The two builds weren't _completely_ identical, but he
differences shouldnt have been much.

> One potential source is runtime libraries.  ADS's library
> structure is pretty granular, and their linker seems to be
> pretty good at discarding unused code.  GNU-compatible runtime
> libraries don't seem to be as fine-grained in their
> implementation as ADS, so the GNU linker isn't as helpful at
> keeping unused modules and/or functions out of the resulting
> image.  Or maybe it's because the GNU linker is more
> simplistic, and the library architecture isn't the source of
> the bloat.  Dunno.

If you put each function in a separate section, and turn on
garbage collection in the linker, then the granularity of the
linking process should be at the function level rather than at
the object file level.  Without those options enabled, you
might end up with a fair number of un-needed library functions.

-- 
Grant Edwards
grante@visi.com

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Vincent Rubiolo]

Hello to you all,

Dan :
Sorry not to have mentioned that : I was talking about stripped images and yes 
the difference is huge (unstripped: 1.8 Mb, stripped : 270 kb :)

Bill and Grant :
[...]
> I've recently compared size/performance of an eCos application
> built w/ 2.95.x and with 3.2.x, and I've seen a size reduction
> of about 20% or so, along with a corresponding increase in
> performance.
> The two builds weren't _completely_ identical, but he
> differences shouldnt have been much.
I did not do tests with 2.95.x but the proceedings of the gcc summit about 
optimising for space seem to draw the same conclusions as your do : 3.x is 
better than 2.95.x (doc here : www.linux.org.uk/~ajh/gcc/ 
gccsummit-2003-proceedings.pdf, very interesting but for pure ARM code only)
I am not too familiar about eCos. Is interworking enabled in it? This is because 
I think the problem might come from here.
> 
>>One potential source is runtime libraries.  ADS's library
>>structure is pretty granular, and their linker seems to be
>>pretty good at discarding unused code.  GNU-compatible runtime
>>libraries don't seem to be as fine-grained in their
>>implementation as ADS, so the GNU linker isn't as helpful at
>>keeping unused modules and/or functions out of the resulting
>>image.  Or maybe it's because the GNU linker is more
>>simplistic, and the library architecture isn't the source of
>>the bloat.  Dunno.

Completely agree on that point. The Perl scripts I use to calculate sizes report 
differences for up to 30% in size for runtime libraries. I will try to tweak 
newlib to build it with -fdata-sections and -ffunction-sections. It should then 
give good results.
After having experimented a while with ld, I would not say that it is so 
simplistic : garbage collecting/selective linking is really helpful with 
-ffunction-sections and -fdata-sections, you just have to enable it. The general 
design of ld makes you think about what you want to achieve : ADS linker 
performs certain optimisations for you, ld gives you full control of the linking 
process.

> If you put each function in a separate section, and turn on
> garbage collection in the linker, then the granularity of the
> linking process should be at the function level rather than at
> the object file level.  Without those options enabled, you
> might end up with a fair number of un-needed library functions.
Correct. I enabled such an option last Friday after my previous post and looked 
at the logs during the WE : 5% gain in size! This is very good news since RAM 
usage is really a concern on our system (the gain corresponds to around 2kb). As 
I stated, I will try to build newlib in such a way.

I'll let you know how it goes.

Thanks for all you advices.

Regards,

Vincent

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB

[Grant Edwards]

On Sun, Aug 24, 2003 at 10:24:13PM +0200, Vincent Rubiolo wrote:

> I did not do tests with 2.95.x but the proceedings of the gcc
> summit about optimising for space seem to draw the same
> conclusions as your do : 3.x is better than 2.95.x (doc here :
> www.linux.org.uk/~ajh/gcc/ gccsummit-2003-proceedings.pdf, very
> interesting but for pure ARM code only) I am not too familiar
> about eCos. Is interworking enabled in it?

Not in the configuration I use.  

> This is because I think the problem might come from here.

> I will try to tweak 
> newlib to build it with -fdata-sections and -ffunction-sections. It should then 
> give good results.

The build configuration for eCos uses -fxxxx-sections and then
garbage-collection of sections by ld, and it works well.  If a
function isn't called by anybody, it isn't included in the
final image -- even if other functions in the same object file
are required.

No more worrying about whether you should put each library
function in a seperate source file (which violates
encapsulation by requiring a lot of things be global when they
should be statically scoped), or group them "logically" into
fewer, larger files in order to provide encapsulation and
data-hiding (which used to pull in un-needed functions).

-- 
Grant Edwards
grante@visi.com