I said it was pseudo code. || is the concatenation operation in PL/1. &1 is is the macro variable. If the line number __LINE__ is 10 then L||&1 would be L10. My request was for #define to generate a unique label. The macro is defined once and used multiple time all over the code. I don't know what the label will be that is why I have to generate it. So that I know what it will be. #define is not a macro processor with variables so I guess it can't be done.

It depends on what you are trying to do...

I still have no idea. The best guess so far is just that you are creating a function to return an address that is in the code segment (a most unsafe construct). But why is unknown. The GNU C compiler allows a lot of things to be done... and without assembly. The only time assembly becomes necessary is to interface directly with device registers - and even then, it depends on what you are doing (sometimes just making a pointer to the device register address is sufficient).

And #define can define macros with parameters.

It is for an RTOS for the microchip PIC1XF1XXX series of computers. The microchip XC8 C compiler is a GCC spinoff. I need to get the return address when I do a YIELD or DELAY() macro to know where to start off from when the task becomes ready again. I will just do a MOVLW LOW $+5 (and high) to get the address if I can't get a unique label.

Ah - a coroutine.

Your best bet would be a bit of assembly just to get the return address. A label wouldn't do as the context would be wrong and jumping to it would not restore the rest of the context (stack/subroutine calls...)

One thing you might consider is the source to the "longjmp" and "setjmp" library functions as that is exactly what it does. The jmp_buf is a system specific structure that is used to save a context. For a lightweight thread library there will need to be multiple stacks, and the "longjmp" re-implemented a bit. The yield() would use setjmp to save the current context, and then use the longjmp to restore a different context. The major issue is thread creation where you have to have access to multiple stacks (you might even be able to use static arrays for a stack, they just have to be large enough for the thread usage+any runtime the thread might use).

The data structure used here is the "jmp_buf" which I believe has to be custom to the hardware. Basically, it boils down to a stack pointer, and any specific things the architecture needs (on x86 it is an array of 6 ints for 32 bits CPUs or 8 long ints for 64 bit CPUs).

Forgot to mention it is necessary to save any floating point status and registers too.

The special thing that has to be handled is identifying the stack entry so that you can modify it correctly when creating a thread.

But as a pointer to an implementation, yours would be custom - you can make it anything you really want, by saving everything on the stack the jmp_buf becomes nothing but a stack pointer... which makes it easy. The actual implementation would still need some assembly code to save the context... and then save the stack pointer, select the next stack pointer - set it (this would be the context change), restore registers and then return.

Unfortunately I only have 256 bytes of ram in the PIC12F1840. For most pics 12F and 16F the stack and its contents are unaccessable except by CALL, CALLW, RETURN, RETFIE So all OS calls need to be at the top of the stack. PIC1XF1XXX devices can access the upper and lower 8 bit top of stack registers as well as the stack pointer. This is why my OS is so small and only has YIELD and DELAY(tics). It does have 3.5k words of flash which is plenty big for the os and routines.

I only have 256 bytes ram in the PIC12F1840. Most PIC12F and 16F have no access to the hardware stack except through call/return statements. PIC1XF1XXX machines have access to the stack pointer and top of stack register. All OS calls must be from the top routine, not a subroutine. The tasks can call subroutines as long as they all return to the top most routine before they make an os call like YIELD. I can fit 3 or 4 tasks (prob more) plus my work routines in 256 bytes of ram. Flash is 3.5K words. Would be able to do routines for wind, light humidity and temp for the crazy chinese humid/temp chip.

Then I would expect you have to program it in assembly.

And there is no OS (in the usual sense) involved. Just a runtime library.

could maybe use C, but don't count on threads - they won't exist. Just a single loop, with a switch statement, and a case for each "task". That would make it the easiest for the compiler to keep things small.

I have written most of the RTOS already. 80 lines of assembly and about 40 lines of C. I have gotten a 400 line C program in 3.5k words on the PIC16F machines.

I would have thought the overhead would not be worth it.

As you say, no subroutines.

Even an 8008 supported more.

And 400 lines of C is sufficiently small to ignore an OS other than a simple loop and switch.

Take a look at this web site as it deals with documentation - especially sphinx which looks good - see: http://www.techrepublic.com/blog/fiv...tag=RSS56d97e7

Interesting... Sphinx actually looks reasonable.

I usually use tgif for diagramming as it allows URL links from diagram to diagram, as well as image imbedding (tiff, gif, png) and generation of the same (though I never used tiff, mostly gif) and postscript.

For text I just learned to use html directly. Not that hard, and only needed to add a CSS entry for block indents.

I have tried other ways, but just found them a bit cumbersome (just personal), I used OpenOffice to document a prototype hierarchical storage system (worked, but sometimes diagrams were balky, but I found dealing with a word processor slower than typing text). I've used docuWiki for a collaborative system documentation, but found it a bit limiting (it used reStructuredText, or at least an early form) for its files.

Have you heard of APPLE swift? http://pietschsoft.com/post/2014/06/...anguage-Syntax

Yes. Right now though, there is only one implementation - Apples.

It also looks like it is designed (like C#) to lock developers into a single vendor.

But I'm not sure. It really depends on how much information they actually release, and whether the language is actually more useful than Objective C. One of the criticisms I have seen is that it doesn't have support for concurrency, and doesn't provide protection against errors from external concurrency support any more than any other language does (well, excluding Ada and Algol68 family and some others).

It is still a new language though, and evolution may make it more accepted and available.

In 1985 I was designing a visual programming language and went to the Apple convention in San Francisco. I met some of the original MAC designers and shook hands with the then president Scully. They asked what people were doing and I stood up and mentioned my project. I think that was the first time the terms Visual and Programming were used together. Someone else named their product with that name. At the time the Lisa 2/10 with a ram loaded MAC/XL was used for development. I bought the $6000 computer and apple immediately went to the MAC Plus for development. I felt abandoned and switched to the windows PC. I did port the STAGE II macro processor to the MAC/XL and wrote an abstract programming language in macros that I had hoped would be portable as long as the STAGE II context sensitive macro processor was ported to the machine in question. I purchased one share of apple stock in order to get on their investor mailing list for $20. It split into 4 but before Steve Jobs returned I sold it. It probably would have been worth a small fortune if I had kept it. Every time apple comes out with a new OS you would have had to buy a new machine. There is a professor here who lives in floyd who has a computer museum with some of the apple 1 original hand made boards and also some that aren't populated. He was the computer guy in chemistry and the Titus brothers and their fame came out of that group.

Been working on the RTOS but came to a stopping point and started work on the BASIC interpreter again. Started out with DIM statements then took that out for a PL/1 Declare statement then took that out and went to a c Type statement for int, string, float, char and bit. Only one type per line with multiple variables separated by commas. No initialization yet. Let the user do that with a subroutine. But maybe later. User now force to declare all variables with no special characters appended onto the variable like $ for string. Put bit in but have not implemented that data type yet. After using it for a while may put that in if needed. Assignment is assumed if the first token is a variable name followed by = sign. How is it going with you? Maybe you should develop for a machine so you get some use or income from your work. Do not know if I will ever go open source with this program. Found out today that I can't use calloc on PIC 8 bit machines. Will have to have the user declare task control blocks and give them numbers. Now I know why http://www.pumpkininc.com did that for the port of their RTOS SALVO to the pic using microchip's MPLABX and XC8. (actually they used the HIGHTECH C compiler under MPLAB). Andrew Kalman who came up with SALVO is a real nice guy who helps out a lot of people.