[ECOS] vrc437x virtual vector support

[ECOS] vrc437x virtual vector support

[Motoya Kurotsu]

Hi, all;

I'm looking at the latest code of vrc4373 platform. I have two points.

1) I assume that the conditional branch by CYGSEM_HAL_VIRTUAL_VECTOR_DIAG 
is necesarry in hal_daig.c/hal_diag.h such like some other platforms.

2) In plf_serial.c, I guess that cyg_hal_plf_serial_xxx functions 
should be enbraced by #ifndef CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE or 
#if CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS rather than 
#ifdef CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT according to the original meaning 
that applications use the ROM monitors resources. In other words, 
is it necessary that applications include the code of these functions?

Regards,
Motoya Kurotsu
Allied Telesis K.K.

Re: [ECOS] vrc437x virtual vector support

[Jonathan Larmour]

Motoya Kurotsu wrote:
> 
> Hi, all;
> 
> I'm looking at the latest code of vrc4373 platform. I have two points.
> 
> 1) I assume that the conditional branch by CYGSEM_HAL_VIRTUAL_VECTOR_DIAG
> is necesarry in hal_daig.c/hal_diag.h such like some other platforms.
> 
> 2) In plf_serial.c, I guess that cyg_hal_plf_serial_xxx functions
> should be enbraced by #ifndef CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE or
> #if CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS rather than
> #ifdef CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT according to the original meaning
> that applications use the ROM monitors resources. In other words,
> is it necessary that applications include the code of these functions?

There does seem to be something odd right now. In a fully virtual vectored
HAL, there should be no need for the current contents of hal_diag.c.
Instead the hal_diag.h should point straight at the hal_if functions in
hal/common's hal_if.c. I'm surprised adding that extra GDB mangling works
without things getting double mangled. Nick?

And by the looks of it, platforms should indeed be conditionalising on
CLAIM_COMMS really (although the bloat should be limited if selective
linking works for your target, which it does for mips). 

This is just HALs inheriting old code - previously the virtual vector
configuration was not as rich (it used to be all or nothing). Good point
anyway.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] vrc437x virtual vector support

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:

>> 2) In plf_serial.c, I guess that cyg_hal_plf_serial_xxx functions
>> should be enbraced by #ifndef
>> CYGSEM_HAL_VIRTUAL_VECTOR_INHERIT_CONSOLE or #if
>> CYGSEM_HAL_VIRTUAL_VECTOR_CLAIM_COMMS rather than #ifdef
>> CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT according to the original meaning
>> that applications use the ROM monitors resources. In other words,
>> is it necessary that applications include the code of these
>> functions?

Most other platforms that are VV enabled do the table initialization
unconditionally. The decision of whether to call the _init() function
is made in hal_if.c (according to CLAIM_COMMS).

The vrc4373 code looks different because it predates the VV magic and
retains (configurably) the old behavior (i.e., non-vectored calls to
the IO functions).   Actually, I think (if anything) it should be
conditional on CYGINT_HAL_VIRTUAL_VECTOR_SUPPORT_NOT_GUARANTEED which
is the piece of magic intended to help platform HALs move from the old
world to the new one. 

However, seeing as CYGSEM_HAL_VIRTUAL_VECTOR_SUPPORT is calculated 1
(and is implemented by the platform HAL), the #ifdefs may just as well
be removed like in most other platfor HALs. Present eCos apps will not
run under old vrc437x stubs anyway...

Jonathan> And by the looks of it, platforms should indeed be
Jonathan> conditionalising on CLAIM_COMMS really (although the bloat
Jonathan> should be limited if selective linking works for your
Jonathan> target, which it does for mips).

No, they should not be conditionalising anything. The CDL decisions
are made and acted upon in the common HAL. The platform code is called
if needed and will be linker GC'd if not. At least that was the plan.

Jesper

Re: [ECOS] vrc437x virtual vector support

[Jonathan Larmour]

Jesper Skov wrote:
> 
> Jonathan> And by the looks of it, platforms should indeed be
> Jonathan> conditionalising on CLAIM_COMMS really (although the bloat
> Jonathan> should be limited if selective linking works for your
> Jonathan> target, which it does for mips).
> 
> No, they should not be conditionalising anything. The CDL decisions
> are made and acted upon in the common HAL. The platform code is called
> if needed and will be linker GC'd if not. At least that was the plan.

Ah, so you _are_ relying on linker GC :-). As you see, I was hinting that
it would be relying on it working. If you're happy making that assumption
(that linker GC is on and working) then okay, but as long as you realise
that's the assumption being made. I thought in general we tried to hard
code the conditionals on the basis of double checking assumptions (and
reducing compile time).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] vrc437x virtual vector support

[Jesper Skov]

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@redhat.com> writes:

Jonathan> Jesper Skov wrote:
>>
Jonathan> And by the looks of it, platforms should indeed be
Jonathan> conditionalising on CLAIM_COMMS really (although the bloat
Jonathan> should be limited if selective linking works for your
Jonathan> target, which it does for mips).
>>  No, they should not be conditionalising anything. The CDL
>> decisions are made and acted upon in the common HAL. The platform
>> code is called if needed and will be linker GC'd if not. At least
>> that was the plan.

Jonathan> Ah, so you _are_ relying on linker GC :-). As you see, I was
Jonathan> hinting that it would be relying on it working. If you're
Jonathan> happy making that assumption (that linker GC is on and
Jonathan> working) then okay, but as long as you realise that's the
Jonathan> assumption being made. I thought in general we tried to hard
Jonathan> code the conditionals on the basis of double checking
Jonathan> assumptions (and reducing compile time).

We could do that - but then we should do it in CDL. No reason at all
to build the file...

Jesper