Wrapping XC in c++ is rubbish

[Interactive_Matter]

or ADC(channel=2) :> sample

But what if the answer is a bit more complicated (e.g. has a timestamp):

ADC(channel=2):> message

if (message.timestamp .... do something

??

Code: Select all

ADC[2] :> sample;
if(sample.ts == somecondition) do something;

But I wouldn't actually do it this way because its not structured

Not sure why you would branch on the sample timestamp?

regards
Al

Hmm, FPGA world ok, convinced

A more structured example might be example:

Code: Select all

select {
  case ADC[2] :> sample : {
    switch(sample.ts) {
      case TS1 : do ts1 thing;
      case TS2 : do ts2 thing;
      default : do default thing;
    }
  }
}

Yes the use case is for illustration purpose only. I do not think switching on a time stamp makes any sense. But you are right.
And perhaps you have already given the answer to one of my questions:

Messages are structs - or at least the body of the message. This could give quite an easy way to specify protocols.
Message IDs are 'methods'. OK

So we got services/modules and module contracts (e.g. by message numbers and expected/provided structs).
What is still missing is implementing and reuse of contracts - and this gives quite a complicated control structure - lots of switch/case implementations.

Will go back with the new knowledge and think about it.

Two thinkgs still puzzle me:
- Understood that XMOS is much more FPGA like than MCU like. Nevertheless it can be an MCU. Perhaps there is some layering model. Lower layers are FPGA layers, higher layers can be more MCU-like layers. Do those MCU layers exist? OR is it just me?
- Objective C (or C++) CAN be an implementation language for those layers but is not really needed. To make it real flexible and easy an better XC version with defined modules, private variables and protocols can be better. But what buildung blocks do we need there (modules/services, private data, instance data(?), contracts, flexible interpretation of contracts(?).

Will keep that in my mind and think about it while I am implementing my stuff .

Thanks for the clarification so far. Understood a lot!

[octal]

nice Fonknology ... really nice examples!

This post should be part of the WIKI :ugeek:

[Folknology]

- Understood that XMOS is much more FPGA like than MCU like. Nevertheless it can be an MCU. Perhaps there is some layering model. Lower layers are FPGA layers, higher layers can be more MCU-like layers. Do those MCU layers exist? OR is it just me?

I think what is important isn't FPGA vs MCU but rather Events vs Interupts.

- Objective C (or C++) CAN be an implementation language for those layers but is not really needed. To make it real flexible and easy an better XC version with defined modules, private variables and protocols can be better. But what buildung blocks do we need there (modules/services, private data, instance data(?), contracts, flexible interpretation of contracts(?).

Also it would benefit you greatly to familiarise yourself with CSP in contrast to OO. CSP deals with concurrency OO does not. CSP lends it's self to event/behaviour based programming supporting underlying XS1 features. XC implements at least at some level CSP.

Contracts can be formalised with the addition of protocols sorely missing from XC, for now use existing types/structures and good documentation/implementation

I am already working on some examples of component based modular construction with Amino and will follow up with some conversation starters on that soon (I'm tied up with the hardware at the moment)

P.S. a more complete implementation of CSP is Occam so its worth taking a look at this also.

regards
Al

[Interactive_Matter]

- Understood that XMOS is much more FPGA like than MCU like. Nevertheless it can be an MCU. Perhaps there is some layering model. Lower layers are FPGA layers, higher layers can be more MCU-like layers. Do those MCU layers exist? OR is it just me?

I think what is important isn't FPGA vs MCU but rather Events vs Interupts.

Need more experience ;)

…

Also it would benefit you greatly to familiarise yourself with CSP in contrast to OO. CSP deals with concurrency OO does not. CSP lends it's self to event/behaviour based programming supporting underlying XS1 features. XC implements at least at some level CSP.

Contracts can be formalised with the addition of protocols sorely missing from XC, for now use existing types/structures and good documentation/implementation

I am already working on some examples of component based modular construction with Amino and will follow up with some conversation starters on that soon (I'm tied up with the hardware at the moment)

P.S. a more complete implementation of CSP is Occam so its worth taking a look at this also.

regards
Al

You gain some you loose some - so I have to digg deeper into CSP first.

Thanks for the clarification, will come back to this until I got a clearer view (may take months ;))

It was a great conversation!

[octal]

Sorry, but this CSP and OCCAM are driving me crazy :ugeek:

Just to amend this topic, I found an interresting post about a teacher who removed the OOP programming from the introductory curriculum "because it is both anti-modular and anti-parallel by its very nature" as he said :)

http://existentialtype.wordpress.com/20 ... -freshmen/

the comments to the post are also nice !!! :ugeek:

[Folknology]

I think their move is a good idea.

For me OO's encapsulation of state is a concurrency trap, one I have experienced to many times.

Having spent years working with both OO and Functional programming langs I have come to prefer functional for more projects requiring concurrency. Also more of my recent projects have involved concurrency so it becomes more self fulfilling of course.

Many modern day problems require concurrent solutions so this is likely to arise even more frequently in future.

With XC however we are in a weird hinterland somewhere between procedural (from C) and CSP, I am hoping that we can move more toward CSP in the near future rather than backward toward C or worse sidewards toward C++.

What are everyone else's thoughts on which way XC should go given the conversation in this thread?

regards
Al

[Interactive_Matter]

Just to amend this topic, I found an interresting post about a teacher who removed the OOP programming from the introductory curriculum "because it is both anti-modular and anti-parallel by its very nature" as he said :)

http://existentialtype.wordpress.com/20 ... -freshmen/

the comments to the post are also nice !!! :ugeek:

I do not think it is worth a war this against that (whatever that is ;) ). I think object hierarchies have their reasons. Funnily enough the mor OO implementations I do the more often I use OO for data and the less often I use OO for modules. And more interestingly more and more often I separate between modules or services and data.

I am mostly working in web development - so a good mixture of concurrent and single threaded programming (the data base is concurrent - often - and answering a single response is a very single threaded action).

As folknology put it services are intrinscly stateless because any state inside a concurrently used service is a guarantee for problems.

I also studied software architecture at university and interestingly enough OO is just one architectural style. The only real thing that is capable of describing software architectures (it is neiter that ard or drastic, but to make my point I express it drastically) is haveing modules which interchange data over interfaces.

To answer folknology's question:

I think what we need is a definition of an interface as protocol or similar.
Methods and data have to be contracts, flexible and strict at the same time (a mandatory core and optional parts).
There need to be pure computation functions (in contrast to methods) for code reuse and modularization (e.g. an abs() function or an calculateThisAndThat() function)
There have to be modules with private data.
Perhaps contracts for modules and method data need to be hierarchical (as in OO) since there always can be modules that offer more specific contracts but are also able to support a more general contract (e.g. a I2C module, which offers a standard I2C contract and can also offer an extended I2C contract with selectable communication speed). If it is hierarchical or just an easy 'contrac-mapping' I don't know right now.
And I think that we need full communication support between XC, C and C++ so that any component written in any langauge can be reused (e.g reusing a light weight web server implementation and gradually porting all time critical or concurrency critical parts to XC).