e500 SPE support

[Justin Hibbits]

You can find it on amazon, http://www.amazon.com/Mikrotik-RB800-RouterBOARD-MiniPCI-RouterOS/dp/B00D84KR76/ref=sr_1_1?ie=UTF8&qid=1444599696&sr=8-1&keywords=RouterBoard+RB800 
  .

It's kind of expensive, but FreeBSD netboots fine on it (I'm working  
on getting it to locally boot).  I thought FreeBSD would boot on the  
p2020, can you tell me what doesn't work for it?

- Justin

On Oct 9, 2015, at 5:07 PM, Thomas Rix wrote:

> I have a p2020rdb I would prefer to use but it doesn¹t seem to have
> freebsd kernel support so toolchain work is only on linux.
> Please send me a link to where you bought your board, I will see about
> getting one.
> Thanks,
> Tom
>
> ---
> Tom Rix
> Sr. Staff Compiler Engineer
> trix at juniper.net
>
>
>
>
>
> On 10/9/15, 2:14 PM, "Justin Hibbits" <chmeeedalf at gmail.com> wrote:
>
>> After talking with others, I'll be creating a new target,
>> powerpc/powerpcspe.  This will live in a branch while I stabilize it
>> (I'll create a branch this weekend).  My testing will be on the
>> Mikrotik RouterBoard RB800, but if anyone has hardware they can test
>> on, all the better.
>>
>> To keep things simple, I'll be overloading the enable_vec()/ 
>> save_vec()
>> functions, and using this common API between Altivec and SPE.
>>
>> - Justin
>>
>> On Tue, Oct 6, 2015 at 10:30 AM, Thomas Rix <trix at juniper.net> wrote:
>>> I see the spe feature is in ToT llvm, but not no target is has this
>>> enabled by default.
>>> What hardware/software are you using to exercise the feature ?
>>> Asking so I could play too :)
>>>
>>> Likely folks wanting the feature would be willing to trade off with
>>> altivec.
>>> So mutually exclusive for me.
>>>
>>> Sprinkling code with spe specific seems clunky.
>>> Could there be some task bit that linker/compiler sets that the  
>>> loader
>>> uses to do this automagically ?
>>> A tie into the task state would help with ptrace and possible  
>>> debugger
>>> support.
>>>
>>> Tom
>>>
>>> ---
>>> Tom Rix
>>> Sr. Staff Compiler Engineer
>>> trix at juniper.net
>>>
>>>
>>>
>>>
>>>
>>> On 10/4/15, 9:14 PM, "owner-freebsd-ppc at freebsd.org on behalf of  
>>> Justin
>>> Hibbits" <owner-freebsd-ppc at freebsd.org on behalf of
>>> chmeeedalf at gmail.com>
>>> wrote:
>>>
>>>> I've been doing some work on the e500 Signal Processing Engine  
>>>> (SPE,
>>>> sort of like Altivec, only weirder), but have some questions on
>>>> implementation:
>>>>
>>>> * This is mutually exclusive to Altivec, of course, because it  
>>>> shares
>>>> the GPRs, extending them to 64-bits, but only for SPE instructions.
>>>> Should the implementation be mutually exclusive, as well?  
>>>> Meaning, is
>>>> it better to have enable_spe()/save_spe() strewn throughout the  
>>>> code,
>>>> like is done with Altivec and FPU, or is it better to name them
>>>> *_vec(), and have a compile-time option of switching between  
>>>> Altivec
>>>> and SPE? The userland ABI would be different as well, which  
>>>> brings the
>>>> next question:
>>>>
>>>> * Do we want another target, like how Linux does it  
>>>> (powerpcspe)?  Or
>>>> have this as just a different build option in src.conf?
>>>>
>>>> Suggestions are welcome and wanted.
>>>>
>>>> - Justin
>>>> _______________________________________________
>>>> freebsd-ppc at freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>>>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org 
>>>> "
>>>
>