text:
User talk:Enyo~enwikibooks

Dear Enyo: It seems like you're working on a book on Ancient Greece. Can I ask you to shift your attentions to Ancient History as a whole, and the Ancient History/Greece section in particular? I'm a history teacher in middle school, and I'd like to work with you on building this as a general textbook for at least ninth grade. What do you think? Oh, and are there others whose talents we could enlist that I don't know about yet? Andrew Watt 15:48, 2 June 2006 (UTC)

Your account will be renamed
Hello,

The developer team at Wikimedia is making some changes to how accounts work, as part of our on-going efforts to provide new and better tools for our users like cross-wiki notifications. These changes will mean you have the same account name everywhere. This will let us give you new features that will help you edit and discuss better, and allow more flexible user permissions for tools. One of the side-effects of this is that user accounts will now have to be unique across all 900 Wikimedia wikis. See the announcement for more information.

Unfortunately, your account clashes with another account also called Enyo. To make sure that both of you can use all Wikimedia projects in future, we have reserved the name Enyo~enwikibooks that only you will have. If you like it, you don't have to do anything. If you do not like it, you can pick out a different name.

Your account will still work as before, and you will be credited for all your edits made so far, but you will have to use the new account name when you log in.

Sorry for the inconvenience.

Yours, Keegan Peterzell Community Liaison, Wikimedia Foundation 23:08, 17 March 2015 (UTC)

Renamed
 This account has been renamed as part of single-user login finalisation. If you own this account you can |log in using your previous username and password for more information. If you do not like this account's new name, you can choose your own using this form after logging in: . -- Keegan (WMF) (talk) 04:56, 19 April 2015 (UTC)

title: User talk:Enyo~enwikibooks


text:
Talk:Digital Circuits/Logic Operations

I wrote up a template for drawing up a basic truth-table for a 2 input, 1 output logic gate. if you use the template, it will draw a truth table as such:

i figured making an automatic template would help to alleviate some of the pain of constantly drawing up a truth table every time you want one. Also, feel free to edit the above template at Template:Digital Circuits Truth Table if you want to make it prettier, easier to read, etc... --Whiteknight T C E 15:17, 2 November 2005 (UTC)
 * Edited that template and made a new set of templates with snappier names, ability to name the inputs and outputs (with defaults A,B,C,Q) and an optional alignment parameter (defualts to centred). So far, there are templates for 1-, 2-, 3-input tables.
 *  gives:

 * Inductiveload (talk) 15:29, 30 April 2009 (UTC)

Standard for Boolean Symbols?
I teach a digital logic class at a community college and am interested in contributing to this book. I wondered, though, about the logic symbols used in Boolean expressions. While the symbols used in this text for AND, OR, and NOT are mathematically correct, several reference books I have on my shelf (along with the one I use in class) tend to use just common symbols found on a standard keyboard.

Could I suggest that we use the algebraic multiply for AND. Thus, to write "a AND b" we would write "ab" - just as multiply in algebra.

To write OR the algebraic "plus" is used. Thus, "a OR b" is "a + b".

Finally, a simple apostrophy is used for negation. Thus "a NOT OR b" would be "a' + b".

While this may not match some texts (and there seems to be a lot of variety on this standard), it is much easier to type Boolean terms on a standard keyboard using these symbols rather than the "V", overbar, and other symbols.
 * I've been through the page and changed to a style using just the AND = A·B, OR = A+B notation, rather than a mixture. The section on the two different notations stands, so readers will be warned about the other style. IMO, that style is more suitable for discrete mathematics and pure logic. We will be dealing with the practical implications, and thngs like sum-of-product are easier to understand in the times/add form (why do you think it is called sum-of-product rather that disjuntion of conjuction?)
 * While this page always uses the centre-dot to denote the multiplcation to keep it all unambiguous, after this page, I expect to use nothing, so A·B→AB.
 * As for negation, I quite like the overbar, as it extends to the whole expression being negated, and I find the apostrophe to look untidy (along with the exclamation mark). It also concerns me that a prime (usually written with just an apostrophe) is often used to denote things like "next state", and we don't want to tangle up the meanings. Remember there is always the ¬ symbol, which is designed for that use! Inductiveload (talk) 15:29, 30 April 2009 (UTC)

 * Mathematics courses tend to use one notation, and engineering courses tend to use the ⋅ and + notation.
 * The Overbar notation does simplify or eliminate lots of parentheses.
 * Note: for math students, 1 + 1 = 1 in boolean or digital logic context, so the + notation is similar to but not identical to traditional arithmetic. Nickalh (discuss • contribs) 12:11, 1 August 2023 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Talk:Digital Circuits/Logic Operations


text:
Embedded Systems/C Programming

The C programming language is perhaps the most popular programming language for programming embedded systems. (Earlier Embedded Systems/Embedded Systems Introduction we mentioned other popular programming languages).

Most C programmers are spoiled because they program in environments where not only is there a standard library implementation, but there are frequently a number of other libraries available for use. The cold fact is, that in embedded systems, there rarely are many of the libraries that programmers have grown used to, but occasionally an embedded system might not have a complete standard library, if there is a standard library at all. Few embedded systems have capability for dynamic linking, so if standard library functions are to be available at all, they often need to be directly linked into the executable. Oftentimes, because of space concerns, it is not possible to link in an entire library file, and programmers are often forced to "brew their own" standard c library implementations if they want to use them at all. While some libraries are bulky and not well suited for use on microcontrollers, many development systems still include the standard libraries which are the most common for C programmers.

C remains a very popular language for micro-controller developers due to the code efficiency and reduced overhead and development time. C offers low-level control and is considered more readable than assembly. Many free C compilers are available for a wide variety of development platforms. The compilers are part of an IDEs with ICD support, breakpoints, single-stepping and an assembly window. The performance of C compilers has improved considerably in recent years, and they are claimed to be more or less as good as assembly, depending on who you ask. Most tools now offer options for customizing the compiler optimization. Additionally, using C increases portability, since C code can be compiled for different types of processors.

Example
An example of using C to change a bit is below

Clearing Bits PORTH &= 0xF5;  // Changes bits 1 and 3 to zeros using C  PORTH &= ~0x0A; // Same as above but using inverting the bit mask - easier to see which bits are cleared

Setting Bits PORTH |= 0x0A; // Set bits 1 and 3 to one using the OR

In assembly this would be

Clearing Bits BCLR PORTH,$0A ;//Changes bits 1 and 3 to zeros using 68HC12 ASM

Setting Bits BSET PORTH,$0A ;//Changes bits 1 and 3 to ones using 68HC12 ASM

Special Features
The C language is standardized, and there are a certain number of operators available that everybody knows and loves. However, many microprocessors have capabilities that the C compiler may not make use of. The C compiler may produce less efficient machine code than hand written assembly language. For instance, both the 8051 and PIC microcontrollers have assembly instructions for directly setting and checking individual bits within a byte. The C program can be written to affect bits individually using "bit fields", but the resulting machine code output from the compiler may not be as fast as the bit-at-a-time machine operations on some microprocessors.

Bit Fields
Bit fields are a topic that few C programmers have any experience with, although it has been a standardized part of the language for some time now. Bit fields allow the programmer to access memory in unaligned sections, or even in sections smaller than a byte. Let us create an example:

struct _bitfield { flagA : 1; flagB : 1; nybbA : 4; byteA : 8; }

The colon separates the name of the field from its size in bits, not bytes. Suddenly it becomes very important to know what numbers can fit inside fields of what length. For instance, the flagA and flagB fields are both 1 bit, so they can only hold boolean values (1 or 0). the nybbA field can hold 4 bits, for a maximum value of 15 (one hexadecimal digit).

fields in a bitfield can be addressed exactly like regular structures. For instance, the following statements are all valid:

struct _bitfield field; field.flagA = 1; field.flagB = 0; field.nybbA = 0x0A; field.byteA = 255;

The individual fields in a bit field do not take storage types, because you are manually defining how many bits each field takes. ''See also "Declaring and Using Bit Fields in Structures"; "Allowable bit-field types".

However, the fields in a bitfield may be qualified with the keywords "signed" or "unsigned", although "signed" is implied, if neither is specified.

If a 1-bit field is marked as signed, it has values of +1 and 0. Allow me to quote from BitField: A signed 1-bit bit-field that can contain 1 is a bug in the compiler.

It is important to note that different compilers may order the fields differently in a bitfield, so the programmer should never attempt to access the bitfield as an integer object. Without trial and error testing on your individual compiler, it is impossible to know what order the fields in your bitfield will be in.

Also bitfields are aligned, like any other data object on a given machine, to a certain boundary.

The C language supports setting up a structure that exactly matches the byte and bit-level layout of a memory-mapped I/O device.

const
A "const" in a variable declaration is a promise by the programmer who wrote it that the program will not alter the variable's value.

There are 2 slightly different reasons "const" is used in embedded systems.

One reason is the same as in desktop applications:

Often a structure, array, or string is passed to a function using a pointer. When that argument is described as "const", such as when a header file says void print_string( char const * the_string ); , it is a promise by the programmer who wrote that function that the function will not modify any items in the structure, array, or string. (If that header file is properly #included in the file that implements that function, then the compiler will check that promise when that implementation is compiled, and give an error if that promise is violated).

On a desktop application, such a program would compile to exactly the same executable if all the "const" declarations were deleted from the source code -- but then the compiler would not check the promises.

When some other programmer has an important piece of data he wants to pass to that function, he can be sure simply by reading the header file that function will not modify those items. Without that "const", he would either have to go through the source code of the function implementation to make sure his data isn't modified (and worry about the possibility that the next update to that implementation might modify that data), or else make a temporary copy of the data to pass to that function, keeping the original version unmodified.

storing data in ROM
Another reason to use "const" is specific to embedded systems:

On many embedded systems, there is much more program Flash (or ROM) than RAM. A ".c" file that uses a definition such as   char * months[] = { "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", }; forces the compiler to store all those strings in program Flash, then on boot-up, to copy those values to a location in RAM. That wastes precious RAM if, as is often the case, the program never actually modifies those strings. By modifying the declaration to   char const * const months[] = { ... };, we inform the compiler that we promise to never modify those strings (or their order in the array), and so the compiler is free to store all those strings in program Flash, and fetch the original value from Flash whenever it is needed. That saves RAM for variables that really do change.

(Some compilers, if you use definitions such as   static char * months[] = { ... };, are smart enough to work out for themselves whether or not that the program ever actually modifies those strings. If the program does modify those strings, then of course the compiler must put them in RAM. But if not, the compiler is free to store those strings only once, in program Flash).

storing data in ROM on a Princeton architecture microcontrollers
Princeton architecture microcontrollers use exactly the same instructions to access RAM as program Flash.

C compilers for such architectures typically put all data declared as "const" into program Flash. Functions neither know nor care whether they are dealing with data from RAM or program Flash; the same "read" instructions work correctly whether the function is given a pointer to RAM or a pointer to program Flash.

storing data in ROM on a Harvard architecture microcontrollers
Unfortunately, Harvard architecture microcontrollers use completely different instructions to access RAM than program Flash.(Often they also have yet another set of instructions to access EEPROM, and another to access external memory chips). This makes it difficult to write a subroutine ( such as puts ) that can be called from one part of the program to print out a constant string (such as "November") from ROM, and called from another part of the program to print out a variable string in RAM.

Unfortunately, different C compilers (even for the same chip) require different, incompatible techniques for a C programmer to tell a C compiler to put data in ROM. There are at least 3 ways for a C programmer to tell a C compiler to put data in ROM.

(1) Some people claim that using the "const" modifier to indicate that some data is intended to be stored in ROM is an abuse of notation. Such people typically propose using some non-standard attribute or storage specifier, such as "PROGMEM" or "rom" , on variable definitions and function parameters, to indicate a "typed pointer" of type "value resides in program Flash, not RAM". Unfortunately, different compilers have different, incompatible ways of specifying that data may be placed in ROM. Typically such people use function libraries with 2 versions of each function that deals with strings (etc.); one version is used for strings in RAM, the other version is used for strings in ROM. This technique uses the minimum amount of RAM, but it usually requires more ROM than other techniques.

(2) Some function libraries assume the data is in RAM. When a programmer wants to call such functions with data that is actually in ROM, the programmer must make sure the data is first temporarily copied to a buffer in RAM, and then call that function with the address of that buffer. This technique uses the minimum amount of ROM to hold the library, but it uses more ROM and RAM than the other techniques at every function call that involves data in ROM.

(3) Some function libraries use functions that can handle being called from one place with a string in RAM, and from other places with a string in ROM. This typically requires "fat pointers" aka "generic pointers" that have extra bits that indicate whether the pointer is pointing to something in RAM or ROM. Every time such a library uses a pointer, the executing code checks those bits to see whether to execute the "read from RAM" or "read from ROM" instructions. This is a special case of "fat pointers" and "tagged pointers" used in other systems that execute different code depending on the type of the pointed-to object, where the "pointer" includes both type information and the destination address.

volatile
A "volatile" in a variable declaration tells us and the compiler that the value of that variable may change at any time, by some means outside the normal flow of this section of code. These changes may be caused by hardware i.e. a peripheral, another processor in a multiprocessor system, or an interrupt service routine.

The "volatile" keyword tells the compiler not to make certain optimizations that only work with "normal" variables stored in RAM or ROM that are completely under the control of this C program.

The entire point of embedded programming is its communications with the outside world -- and both input and output devices require the "volatile" keyword.

There are at least 3 types of optimizations that "volatile" turns off:
 * "read" optimizations -- without "volatile", C compilers assume that once the program reads a variable into a register, it doesn't need to re-read that variable every time the source code mentions it, but can use the cached value in the register. This works great with normal values in ROM and RAM, but fails miserably with input peripherals. The outside world, and internal timers and counters, frequently change, making the cached value stale and irrelevant.

 * "write" optimizations -- without "volatile", C compilers assume that it doesn't matter what order writes occur to different variables, and that only the last write to a particular variable really matters. This works great with normal values in RAM, but fails miserably with typical output peripherals. Sending "turn left 90, go forward 10, turn left 90, go forward 10" out the serial port is completely different than "optimizing" it to send "0" out the serial port.

 * instruction reordering -- without "volatile", C compilers assume that they can reorder instructions. The compiler may decide to change the order in which variables are assigned to make better use of registers. This may fail miserably with IO peripherals where you, for example, write to one location to acquire a sample, then read that sample from a different location. Reordering these instructions would mean the old/stale/undefined sample is 'read', then the peripheral is told to acquire a new sample (which is ignored).

Depending on your hardware and compiler capabilities, other optimizations (SIMD, loop unrolling, parallelizing, pipelining) may also be affected.

const volatile
Many people don't understand the combination of "const" and "volatile". As we discussed earlier in Embedded Systems/Memory, embedded systems have many kinds of memory.

Many input peripherals -- such as free-running timers and keypad interfaces -- must be declared "const volatile", because they both (a) change value outside by means outside this C program, and also (b) this C program should not write values to them (it makes no sense to write a value to a 10-key keypad).

compiled and interactive
The vast majority of the time, when people write code in C, they run that code through C compiler on some personal computer to get a native executable. People working with embedded systems then download that native executable to the embedded system, and run it.

However, a few people working with embedded systems do things a little differently.
 * Some use a C interpreter such as    or Interactive C or Extensible Interactive C (EiC). They download the C source code to the embedded system, then they run the interpreter in the embedded system itself. (More C interpreters are listed in another Wikibook, C Programming/C Compilers Reference List).
 * Some people have the luxury of working with "large" embedded systems that can run a standard C compiler (it runs the standard GCC on Linux or BSD; or it runs the DJGPP port of GCC on FreeDos; or it runs the MinGW port of GCC on Windows; or it runs the Tiny C Compiler on Linux or Windows; or some other C compiler). They download the C source code to the embedded system, then they run the compiler in the embedded system itself.

C compilers for embedded systems
Perhaps the biggest difference between C compilers for embedded systems and C compilers for desktop computers is the distinction between the "platform" and the "target". The "platform" is where the C compiler runs -- perhaps a laptop running Linux or a desktop running Windows. The "target" is where the executable code generated by the C compiler will run -- the CPU in the embedded system, often without any underlying operating system.

The GCC compiler is the most popular C compiler for embedded systems. GCC was originally developed for 32-bit Princeton architecture CPUs. So it was relatively easily ported to target ARM core microcontrollers such as XScale and Atmel AT91RM9200; Atmel AVR32 AP7 family; MIPS core microcontrollers such as the Microchip PIC32; and Freescale 68k/ColdFire processors.

The people who write compilers have also (with more difficulty) ported GCC to target the Texas Instruments MSP430 16-bit MCUs; the Microchip PIC24 and dsPIC 16-bit Microcontrollers; the 8-bit Atmel AVR microcontrollers; the 8-bit Freescale 68HC11 microcontrollers.

Other microcontrollers are very different from a 32-bit Princeton architecture CPU. Many compiler writers have decided it would be better to develop an independent C compiler rather than try to force the round peg of GCC into the square hole of 8-bit Harvard architecture microcontroller targets:

SDCC - Small Device C Compiler for the Intel 8051, Maxim 80DS390, Zilog Z80, Motorola 68HC08, Microchip PIC16, Microchip PIC18 http://sdcc.sourceforge.net/

There are some highly respected companies that sell commercial C compilers. You can find such a commercial C compiler for practically every microcontroller, including the above-listed microcontrollers. Popular microcontrollers not already listed (i.e., microcontrollers for which the only known C compiler is a commercial C compiler) include the Cypress M8C MCUs; Microchip PIC10 and Microchip PIC12 MCUs; etc.

title: Embedded Systems/C Programming


text:
User:Lord Voldemort~enwikibooks

'''My personal information and story are no longer important enough to be at the top of my user page... '''

Wikibooks is, despite what others may say, at a turning point. It is on the verge of actually becoming great. However, before any of this can happen, certain policies and guidelines should be in place. Why these were never enforced is a mystery, and complete failure at the beginning of Wikibooks. Some of the missing policies are as follows (If the link goes blue, that does not mean it is enforced. It is probably still a proposed policy... Go express your support!):

Missing Wikibooks policies
Some of the ideas these policies are based on are present, but they need their own policy.
 * Verifiability
 * Cite sources
 * No original research - Please see my sandbox for an adapted start to the No original research policy. Any comments or tweaks are encouraged.
 * No personal attacks
 * No legal threats
 * Deletion policy
 * Editing policy
 * Image use policy
 * Naming policy
 * Protected page
 * Talk page
 * Title pages
 * Blocking policy
 * Banning policy
 * Three-revert rule
 * Assume good faith
 * Civility
 * Don't disrupt Wikibooks to illustrate a point
 * Sock puppet
 * Undeletion policy
 * Consensus
 * Module size
 * No offensive usernames

 * And while not exactly a missing policy, Dispute resolution is very needed. Shouldn't this be in place before we actually need it too badly?

Incomplete policies (my opinion)

 * What is Wikibooks

Personal stuff
I have spent a lot of time over at the English Wikipedia. Normally the best way to contact me is over there at my talk page. Please see Lord Voldemort for my Wikipedia user page and connected talk page.

''I think this user page is extremely boring. Feel free to change it and make it beautiful, I encourage it. Just don't omit too much of the info already here. Thanks.''

I originally just created this account to reserve my name. However, I fell in with the Wikijunior crowd and just love it. I think it could be a very wonderful resource for children. I have spent most of my time at Wikibooks trying to do work with the Wikijunior Big Cats project. Something that could be very interesting, in my opinion.

Ummm... other than that, please see me at Wikipedia to know me better.

Kate's Tool .

My sandbox

Textbook possible topics

title: User:Lord Voldemort~enwikibooks


text:
User talk:207.74.27.130

Please stop adding nonsense to Wikibooks. It is considered vandalism. If you would like to experiment, use the sandbox. Thank you.

title: User talk:207.74.27.130


text:
Talk:Autistic Survival Guide

==Could there possibly be some effort to have all these organisations club together to create an all-in-one website on the disorder, and teach the organisations how to mirror the all-in-one website source==

More importantly could experts create a survival guide, teaching what one should learn to be able to in an order
i.e. one should learn how to do this first, then this, and maybe "but you should read this short section first" there is far too much information to cope with, reading all this makes me suicidal, i have no way of putting it into order. it's far easier to learn to be an arsehole, go to martial arts classes, and scare people who mess with me. i'm not even kidding, far more confidence/self-esteem that way. Never found any problems with NTs in a martial arts class, except maybe the instructors, but there's not much they can do without risking losing income, or is there? But of course, if one follows this path, don't advertise that you do martial arts, unless you have to, as NTs might turn up with a gun :D

Needs warnings section, links not working
There should be some warning section where the reader is told things like not to go with everyone, etc. Some links are either dead or not linking directly to the other guides. 84.129.160.204 (talk)
 * Do you mean external links or links to subchapters? Logictheo (talk) 07:54, 29 May 2009 (UTC)

Thoughts regarding whether the book should remain at wikibooks
Does this article belong here at all, or should it be at Academica Wikicity? Gerrit 17:29, 2 November 2005 (UTC)
 * It belongs here! Gerrit 15:47, 11 December 2005 (UTC)

 * I think it belongs too, but maybe it's welcome on both wikibooks and academica wikicity, but if it is in both places then there would be 2 different versions of the book. I'm not sure whether it would be good or bad. Logictheo 22:57, 23 November 2006 (UTC)

POV (Point Of View)
"Non-autistic people seem to make a game of judging each other by how close they get to 100% (see section on confidence). This may be at least part of the reason that it is difficult to get explanations out of non-autistic people. "

This is aspergers cognicentrism. I know, I have aspergers. The reason why people aren't answering your questions is; A; They lack motivation B; They don't understand your question C; Your question has violated some taboo or social boundary D; Your question has made assumptions which they don't share E; Your question forces an intellectual attitude regarding a topic which the person has only regarded casually.

I'd have to say, please don't remove this wikibook, I could probably use it as source material for a quick game of analysis. Prometheuspan 00:17, 23 February 2006 (UTC)

 * My perspective of this is that it is true that life seems to be a social status game which is described in the confidence section for non-autistic people, which does not seem to be true for most autistic spectrum people.

 * Therefore, considering that status may come from knowing and using certain "social tricks", what I'm saying is that answering reasonable questions may represent giving information to the competition for a non-autistic person.

 * That said, I believe points A thru E are valid in and of themselves, but when they don't apply, it is still difficult to get useful information out of people, and there is obviously some reason for it.

 * Out of interest, what do you mean by "game of analysis"? I feel that this is a put down. Is there something constructive you can add in the way of feedback? 203.214.22.24 12:06, 7 March 2006 (UTC)

 * "My perspective of this is that it is true that life seems to be a social status game which is described in the confidence section for non-autistic people, which does not seem to be true for most autistic spectrum people." 203.214.22.24 12:06, 7 March 2006 (UTC)

 * I'd agree. Aspies in general are more interested in their own intellectual stimulus than the outside world period, and so they aren't very interested in the game of socialization, pack psychology, and so forth. As a side issue, most aspies have some difficulty even comprehending that game, because it is so different a set of motivations and intentions than those aspies are generally operating from. This can be a spiraling problem, because aspies are the certain cure for Groupthink, but thus end up the targets of Status Quo preservers. People assume we are playing the same game they are and using tricks inside of that game. Instead, we are just observing things outside of the box. Prometheuspan 02:50, 8 March 2006 (UTC)

 * "Therefore, considering that status may come from knowing and using certain "social tricks", what I'm saying is that answering reasonable questions may represent giving information to the competition for a non-autistic person." 203.214.22.24 12:06, 7 March 2006 (UTC)

 * I am very interested in game theory and psychology precisely because it enabled me eventually to generate a close approximation for my own purposes to the social game. I think that it is also sometimes true that people are playing the social game, and that is why they balk at aspie -outside of the box- questions and observations. However, MORE OFTEN, the case is the opposite; the person would freely give information, they just don't understand where the aspie is coming from. There are a variety of problems that are being mixed here together accidentally. Each has different causations and different solutions. The best and most important thing to remember as an aspie is to not get stuck in the "US-VS-THEM" destructive spiral. "Assume good faith". (Until good evidence prooves that the person isn't acting in good faith.)

 * "That said, I believe points A thru E are valid in and of themselves, but when they don't apply, it is still difficult to get useful information out of people, and there is obviously some reason for it." 203.214.22.24 12:06, 7 March 2006 (UTC)

 * Reasons Prometheuspan 02:50, 8 March 2006 (UTC)

 * "Out of interest, what do you mean by "game of analysis"? I feel that this is a put down.  Is there something constructive you can add in the way of feedback?" 203.214.22.24 12:06, 7 March 2006 (UTC)

 * I am glad that you asked that question, because I am thinking of making an annotated version of the book to expand on its themes and add clarity from the perspective of Psychology. I am not trying to put the book down, but I am identifying problems in its reasoning process. Constructive energy is more expensive than deconstructive energy, and I apologize. The "Game of Analysis" would have to be taken in context, and I can't remember off the top of my head which way I used it. There are several different Games of Analysis I might have been refering to. The first and most obvious is that Game which Aspies must play in making sense of the strange world. The next is the game a logician must play in making sense of an Aspie. The root problem here is that Aspies and most people THINK in very different ways. Cognitive styles end up generating cognitive biases. The third game is sorting the difference between the first two; Trying to make sense of different cognitive styles. ah, i read my comment, and i meant it in the third way. :) Prometheuspan 02:51, 8 March 2006 (UTC)

 * Thankyou for this. :-)  I'm a little frustrated these days that this book doesn't seem to have enough basics to attract other contributors, and I can't work out how to change that.

 * Please feel free to change it any way you like. 203.214.22.24 20:03, 12 March 2006 (UTC)

 * I don't think it needs to be changed. It is a good book and you have done a fine job of retrofitting it. If I wasn't so busy with THINKSTARSHIP I would def come and do some work, but the way I would do it is to create an annotated version. Prometheuspan 01:57, 14 March 2006 (UTC)

 * 203.214.22.24, please tell me an example of where you would like the basics page. (for example between 1.1.1 and 1.1.2 or at the beginning). Maybe we could have a section regarding on how to read the book in a way that makes the reader aware of the most "basic" ideas of the book. You are also welcome to register on Wikipedia. Logictheo 08:23, 24 November 2006 (UTC)

 * At the moment I'm toying with the idea of breaking the book into sections. The first one would be "basics" and would include all the sections up to but not including the sections about confidence and the social status game.  The next section would be theory about how the non-autistic mind works and would be an expanded version of the section about confidence.  The remaining sections would be about all the side issues that comprise the rest of the book.  CrazyEddy 14:10, 16 December 2006 (UTC)

Took a while to spell check and reshuffle bits and pieces
but I think JVM's work is well deserved and my contribution (even with the recovering due to my old master copy...) is miniscule by comparison. --28481k 82.28.210.194 01:23, 3 June 2006 (UTC)

 * It took me a while to analyze a lot of confusion for me in this discussion. A person replying to a text, split the text in parts and replied to each part separately, which caused great confusion for me seeing no whole original text beeing replied to. (which I'm used to in most discussion pages). Thus many new texts lacking a signing. Logictheo 22:09, 23 November 2006 (UTC)

 * Indeed. I find the whole discussing things by editing pages extremely difficult.  Wikipedia may know about the "never trust a skinny chef" rule but they sure don't know about the "never trust a moribidly obeise one either" rule.  CrazyEddy 13:51, 16 December 2006 (UTC)

section "# 5 More distortions of the truth"
This didn't make sense to me, but after reading it for a while, it made some sense. Do you think this section belongs here, and did you understand it? Logictheo 09:15, 24 November 2006 (UTC)

 * The "looking on the bright side" section came early in Marcs original book.

 * Ok, but what does the section mean anyway? Logictheo 10:02, 4 June 2007 (UTC)

VFD comment - Please Don't Delete
I find the writing by Marc Segar very helpful. I just want to add that a man is not supposed to bent down while in a public shower because it means that he is gay and he wants to have sex. Not knowing this can cause tension or misunderstanding between teamates. I think that this is what Marc Segar is trying to do. He does not teach you to conform. He teaches you to protect yourself in the world where most people don't judge you from the inside, but they judge you by your action and unwritten social rules and will tease you if you are vulnerable. We all know from our heart that the world is not a "happy" place. Notice that Marc teaches that non-austistic people sometimes making fun of other groups to boost their own ego. Marc teaches autistic people to protect themself but not to use the unwritten rule to pick on someone wittier or funnier or pick on someone more shy and quieter.

I don't know if I am autistic or not, but I have trouble picking up unwritten social rules. I suspect that I do not have parents, teachers, or counselors that talk to me about this. I did talk to a few conselors, but they were more damaging than helpful. I discussed to them about my trouble forming relationship with friends. Even though I insisted that there are things that I did wrong that people don't like, the conselors kept telling me that I was paranoid and insecure. Then they go on and lecture to me what a good friendship is. I even gave them some examples and asking them what I did wrong, all they did was laugh. I intuitively understand they they knew what the problem was but they didn't want to tell me that I had violated the unwritten rule. Why? because they are just like everyone else, they want to see me suffer to boost their own ego.

Also, I heard so many people proudly say that, "I don't believe in normal." My reponse to that would be "It's because you have not experience anything else but normal." It is okay to be different, but you just need to protect yourself and that is what Marc Segar teaches in his work.

After reading Marc Segar's book, I felt like finding a flowing river in the middle of the desert. I read somewhere that Marc is dead, but his work may be the eternal fountain of your for millions suffering.

Please don' get rid of this book. My Son is a person on the Autistic Spectrum and I was desperately worried about how to help him understand social rules etc that even I don't fully understand and this book seems to me more precious than gold and I want it to be available to him when he is old enough to read it.

Reorganising the book into wiki chapters
Some chapters are very large, and as the book is now it's about 100 kilobytes, making editing very difficult for me, and probably for others. I suggest we put the really great (in size) chapters in separate "wiki chapters" which make it easier to edit. You will still see all chapters but you won't load the whole book while coming to the main page, since you might also not be interested in everything but only some parts, and when you edit you will edit parts not the whole book at once. What do you say? Logictheo 19:36, 2 May 2007 (UTC)

This is not a reply but more info added to my original message. There is a guideline on wikipedia about article sizes: http://en.wikipedia.org/wiki/Wikipedia:Article_size Logictheo 08:46, 5 May 2007 (UTC)

Yes, I agree. I've often wondered how to break this book into chapters technically, and where the best places to break it are. As for actual editing, there's a FireFox addon called "it's all text" that will put an "edit" tab on every textbox and allow you to launch an actual editor on the content. CrazyEddy 06:35, 8 May 2007 (UTC)

Issues that bother me greatly are that the "printable version" link in the toolbox doesn't actually link the separated chapters into the printable document and that there is absolutely no way to find documents that somehow become unlinked with the rest of the book. It's almost as if MediaWiki has been used for WikiBooks without consideration as to whether it is useful for the task. I'm running into all sorts of insane problems dealing with its interface. CrazyEddy 07:46, 8 May 2007 (UTC)

Descriptions for wiki chapters
I've thought whether we could make small descriptions regarding separate chapters, so people can get more information what the chapter is about. We could maybe set it to at most 2 sentences. What do you say? Logictheo 09:02, 6 May 2007 (UTC)

Again, I agree. I'm a bit of a techhead rather than a writer and at this point I'm just working on content rather than presentation and organisation, so at this point I'm happy to let you or anyone else organise things the way you want. CrazyEddy 06:43, 8 May 2007 (UTC)

Braking the book in subchapters(MediaWiki)
Warning: this is an edited reply, purpose to clear out confusion. (Undo revision 858809 by Logictheo What's wrong with it being a template? Do I have to change the way my book is written because  MediaWiki is a piece of crap?) is explained by CrazyEddy why the page is being brought back to a previous version. You deleted the subpages, and made templates with the same names. Why? I must revert history because of that. If you still wish to revert it, please say why here...because in this way this discussion can lead to some good results. Logictheo 16:14, 10 May 2007 (UTC)

 * I don't fully understand what you just wrote. I didn't actually delete any sub-pages.  I used the " – " notation instead of the "" notation because the " – " notation will insert the sub-document INTO the current document whereas "" simply inserts a link.  The book may be too large to edit, but it is DESIGNED to be small and is by no means too large to load in a browser therefore I would like all the elements to be on one printable page.
 * Now, what exactly is the issue with templates that you have to revert history? I understand that using " – " converts something to a template, but I don't understand exactly what, or what the issue with templates is.  If mediawiki is doing something with documents with " – "'s in them then surely there's another way to achieve the last paragraph, but if you don't mind, I'd prefer to have the document laid out the right way rather than pander to MediaWiki's bugs.  CrazyEddy 16:36, 10 May 2007 (UTC)
 * One thing I would like to add is that breaking the book into sub-documents is a good idea, and I'd like to thank you for doing that. I've been looking for a way to do this for a long time.  The way it stands right now, everything is included on one page for viewing, but the actual page is broken into separate documents, and until I can find a way to have a single printable page, I'd simply rather not break the book into interlinked documents if that's OK with you?  CrazyEddy 17:17, 10 May 2007 (UTC)

 * Well, we could make a separate page which is called "printable version", what do you say? I'm hesitating to make transclusion(yes that's a page on wikipedia I've found regarding the "{}" symbols). It might confuse regular users who have no technical understanding, and just want to add content. I'll do it, and if you object, reply. Even if you agree reply anyway if you like. Logictheo 18:18, 10 May 2007 (UTC)

 * Making a printable version is an ideal solution to me. Also, I'm reading w:Wikipedia:Transclusion and I see nothing there indicating that using " – " is bad.  What exactly is wrong with it?  Can you point me to any page that talks about that?

 * I must say that I've put a hell of a lot of work into this book and that have copyright on 95% of the content. If this issue is not sorted out I'm inclined to remove it from WikiBooks.  CrazyEddy 19:03, 10 May 2007 (UTC)

 * Remove it if you still claim copyright, and you do not agree to the text in capitals(I'm quoting) "DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!". Did you get any permission to submit this copyrighted work? If not remove it, although I've put some time, no problem, remove it. Logictheo 19:28, 10 May 2007 (UTC)

 * If I may interject here, it is actually not legal for you to remove content from Wikibooks once you have donated it. If I may quote Section 9 of the GFDL: "parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance." Wikibooks is the "party" with the license, the copyright holder is "you". By contributing your text to wikibooks, you are granting wikibooks a license to use that material. By the text of the GFDL license, you may not terminate that agreement so long as Wikibooks does not violate the license.
 * Also, on a related note, Wikibooks is a collaborative project and people need to work together. If people don't work together nicely, that's actually a violation of our policy. If you have a question about formatting, or if you would like to ask an outside party to mediate an argument, you may certainly do that. I would recommend posting questions to the staff lounge, and the community will help you out. If you have any questions for me, you can also ask them on my user talk page. --Whiteknight (talk) 20:39, 10 May 2007 (UTC)

 * It was not good of me to name this section "edit wars", it's not very diplomatical, and wiki projects should be. Logictheo 10:06, 4 June 2007 (UTC)

Regarding Marc Segar's Death
I saw the note that staying in the non-autistic world may have caused Segar to kill himself, but I am unable to fine an article that supports this. The only item I can find is a French Wikipedia article that says he died in a car accident. Does anyone have a reference of his suicide?

- My name is Emma Segar; I'm Marc's sister. I'm posting this on a few forums where Marc is mentioned, to clear up any confusion around his life, his guide and his death. Please feel free to contact me if you have any questions about Marc and his work. My e-mail is purplepooka@blueyonder.co.uk

This has been a difficult thing for any of his family to come forward and talk about. Obviously it is upsetting for us, and I think we've also felt for some time that it wasn't really necessary, or appropriate, to make public announcements about Marc on the internet. However, ten years on, finding Marc's name in unexpected places all over the net, from blogs and autism forums to Hollywood film proposals, I'm beginning to realise that, whether we like it or not, public interest in Marc is now a fact, and I would rather put up the facts from our perspective and an e-mail address for questions than keep stumbling across guesses and speculations.

Marc's death: Marc's death was a suicide, not a car accident. He drove out to the M1 in the middle of the night, parked at a services and walked onto the motorway. He was suffering from depression, but not panic attacks as has been suggested, and I believe that he was thinking clearly and knew what he was doing at the time. He had written a very brief note on his computer, which he hadn't shown to anybody or left anywhere it could be accidentally found. It wasn't a cry for help, just a confirmation of intent. There was no one particular event that brought it on, but many contributing factors. We have been through the process of blaming his (mild) drug use, his difficulties in maintaining friendships, the stresses of his work, and of course we have blamed ourselves for not seeing it coming. I still believe that the greatest influence on his decision was the pressure that he put on himself to overcome the barriers of Asperger's Syndrome, and his difficulty in putting those barriers into perspective with his many achievements.

Marc's Guide: The Guide itself wasn't an enduring obsession but a passing interest, which he updated a few times and then dismissed as too incomplete to be useful. He began work on another guide to help with conversations, which was full of lists of band members, football teams, films and TV programmes, so that readers would know what NTs were talking about when they discussed these things. He gave this up when he realised how quickly it would become outdated, not to mention the enormity of the task of writing what was essentially a bluffer's guide to everything.

His view of the non-autistic world, despite his wide experience, extensive research and personal disregard for the conventional, remained irredeemably cut and dried. I remember arguing with him about the first draft of the Guide. I thought it gave the impression that it was somehow wrong or bad to be autistic, and that he should include a passage to the effect that readers didn't have to follow these rules if they didn't want to - it was just background information to help them make a personal choice. He said that those who read it all had to live in this world, and the world wasn't going to change, so there was no choice. I think he changed his mind later, after meeting more people with Asperger's Syndrome, but he never quite made the leap of extending the validity of that choice to himself.

I wish that Aspies For Freedom and all of these blogs had been around then. There was really very little at the time in the way of information or organisations run by and for Aspies, and perhaps a group of that kind might have persuaded him that he could lead the life he wanted to without having to put himself in such intensely stressful situations. I believe that he would have had a lot to say on these forums, and the most difficult thing about posting this is to see him being talked about here, instead of seeing him talk here. Even those who knew him best can't begin to speak for him, but I know he would have had a great deal to say.

Copyright uncertainty of the book - (95% ok. 5% uncertain)
Hi,

from a previous dicussion CrazyEddy mentions that he has copyright on 95% of the work.

> I must say that I've put a hell of a lot of work into this book > and that have copyright on 95% of the content. > CrazyEddy 19:03, 10 May 2007 (UTC)

Who or which people hold copyright on 5% of the original work? Did/do they agree to Wikibook's license "Creative Commons Attribution/Share-Alike License 3.0 and the GFDL"? I had this uncertainty after you mentioned that you have copyright over 95% of the work, so I wondered about the 5% and if this work (95%) was based on a non-free work. Logictheo (talk) 08:22, 13 June 2010 (UTC)

 * My understanding on this is that a free license is still copyrighted by it's author, since this is the only way it can be held under such a license, and that although the work can't retrospectively be unlicensed, it can be re-licensed by its copyright holder for future works.

 * That said, I don't intend to relicense it. My main concern is that the work does have to be as readable as possible to a wide range of autistic spectrum people with a wide mix of intellectual abilities.  The structure of the book is important.  The questions section at the beginning needs to stay there for example, and not be melded into the conversations section.

 * The fact that people keep re-arranging, renaming and splitting off sections is deeply confusing for me because I cannot get a grip on all the changes happening without manually searching for all the individual sections and putting them on my watch list.

 * You need to decide if you want this book to achieve its stated purpose as best as possible or become another wikimedia work of art. You cannot have both.  Or at least, I can't see a way.  This is an important decision, because there are remarkably few effective self help guides out there for autistic spectrum people.  CrazyEddy (talk) 13:01, 11 July 2010 (UTC)

 * Also, I basically started writing this book HERE, on WikiBooks, based on notes I'd previously written which are now far less developed than this page. You can look at the list of contributors over the years in the history.  I forgot to log in a few times while I was writing, but I basically came from the same IP blocks over that time.  Does that answer the original question?  CrazyEddy (talk) 16:40, 25 July 2010 (UTC)

 * Thank you for the clarification, CrazyEddy. I hope this will help Logictheo and others Avoid copyright paranoia.
 * It looks like this book is like most books at Wikibooks -- and most published books -- there's one person who writes over half of the book, and a bunch of other people that interject a bit of material here or there, attempt to improve the arrangement of parts, and fix typos.
 * I agree that arbitrary and frequent re-arranging, renaming and splitting is confusing.
 * On the other hand, if we freeze the current arrangement of the book, then it will be impossible to make any further improvements.
 * I hope we find a middle way. A way that allows people to gradually make this book better and better, but avoids unnecessary confusion. By "better", I mean "more useful for the target audience", not "looks prettier". --DavidCary (talk) 22:32, 25 July 2010 (UTC)
 * I keep hoping that it will continue on its development.
 * I still have things to contribute to it too, but its ground has been too unstable to walk on for me. CrazyEddy (talk) 16:28, 28 July 2010 (UTC)

 * I'd be happy if the book were split into new works. :-)  CrazyEddy (talk) 19:16, 28 July 2010 (UTC)

title: Talk:Autistic Survival Guide


text: User talk:62.214.193.148

title: User talk:62.214.193.148


text: User talk:67.53.1.190

title: User talk:67.53.1.190


text:
Embedded Systems/Mixed C and Assembly Programming

C and Assembly
Many programmers are more comfortable writing in C, and for good reason: C is a mid-level language (in comparison to Assembly, which is a low-level language), and spares the programmers some of the details of the actual implementation.

However, there are some low-level tasks that either can be better implemented in assembly, or can only be implemented in assembly language. Also, it is frequently useful for the programmer to look at the assembly output of the C compiler, and hand-edit, or hand optimize the assembly code in ways that the compiler cannot. Assembly is also useful for time-critical or real-time processes, because unlike with high-level languages, there is no ambiguity about how the code will be compiled. The timing can be strictly controlled, which is useful for writing simple device drivers. This section will look at multiple techniques for mixing C and Assembly program development.

Inline Assembly
One of the most common methods for using assembly code fragments in a C programming project is to use a technique called inline assembly. Inline assembly is invoked in different compilers in different ways. Also, the assembly language syntax used in the inline assembly depends entirely on the assembly engine used by the C compiler. Microsoft C++, for instance, only accepts inline assembly commands in MASM syntax, while GNU GCC only accepts inline assembly in GAS syntax (also known as AT&T syntax). This page will discuss some of the basics of mixed-language programming in some common compilers.

Linked Assembly
When an assembly source file is assembled by an assembler, and a C source file is compiled by a C compiler, those two object files can be linked together by a linker to form the final executable. The beauty of this approach is that the assembly files can be written using any syntax and assembler that the programmer is comfortable with. Also, if a change needs to be made in the assembly code, all of that code exists in a separate file, that the programmer can easily access. The only disadvanges of mixing assembly and C in this way are that a)both the assembler and the compiler need to be run, and b) those files need to be manually linked together by the programmer. These extra steps are comparatively easy, although it does mean that the programmer needs to learn the command-line syntax of the compiler, the assembler, and the linker.

Inline Assembly vs. Linked Assembly
Advantages of inline assembly:

Short assembly routines can be embedded directly in C function in a C code file. The mixed-language file then can be completely compiled with a single command to the C compiler (as opposed to compiling the assembly code with an assembler, compiling the C code with the C Compiler, and then linking them together). This method is fast and easy. If the in-line assembly is embedded in a function, then the programmer doesn't need to worry about, even when changing compiler switches to a different calling convention.

Advantages of linked assembly:

If a new microprocessor is selected, all the assembly commands are isolated in a ".asm" file. The programmer can update just that one file—there is no need to change any of the ".c" files (if they are portably written).

Calling Conventions
When writing separate C and Assembly modules, and linking them with your linker, it is important to remember that a number of high-level C constructs are very precisely defined, and need to be handled correctly by the assembly portions of your program. Perhaps the biggest obstacle to mixed-language programming is the issue of function calling conventions. C functions are all implemented according to a particular convention that is selected by the programmer (if you have never "selected" a particular calling convention, it's because your compiler has a default setting). This page will go through some of the common calling conventions that the programmer might run into, and will describe how to implement these in assembly language.

Code compiled with one compiler won't work right when linked to code compiled with a different calling convention. If the code is in C or another high-level language (or assembly language embedded in-line to a C function), it's a minor hassle—the programmer needs to pick which compiler / optimization switches she wants to use today, and recompile every part of the program that way. Converting assembly language code to use a different calling convention takes more manual effort and is more bug-prone.

Unfortunately, calling conventions are often different from one compiler to the next—even on the same CPU. Occasionally the calling convention changes from one version of a compiler to the next, or even from the same compiler when given different "optimization" switches.

Unfortunately, many times the calling convention used by a particular version of a particular compiler is inadequately documented. So assembly-language programmers are forced to use reverse engineering techniques to figure out the exact details they need to know in order to call functions written in C, and in order to accept calls from functions written in C.

The typical process is:
 * write a ".c" file with stubs ... details??? ... ... exactly the same number and type of inputs and outputs that you want the assembly-language function to have.
 * Compile that file with the appropriate switches to give a mixed assembly-language-with-c-in-comments file (typically a ".cod" file). (If your compiler can't produce an assembly language file, there is the tedious option of disassembling the binary ".obj" machine-code file).
 * Copy that ".cod" file to a ".asm" file. (Sometimes you need to strip out the compiled hex numbers and comment out other lines to turn it into something the assembler can handle).
 * Test the calling convention—compile the ".asm" file to an ".obj" file, and link it (instead of the stub ".c" file) to the rest of the program. Test to see that "calls" work properly.
 * Fill in your ".asm" file—the ".asm" file should now include the appropriate header and footer on each function to properly implement the calling convention. Comment out the stub code in the middle of the function and fill out the function with your assembly language implementation.
 * Test. Typically a programmer single-steps through each instruction in the new code, making sure it does what they wanted it to do.

Parameter Passing

 * Normally, parameters are passed between functions (either written in C or in Assembly) via the stack. For example, if a function foo1 calls a function foo2 with 2 parameters (say characters x and y), then before the control jumps to the starting of foo2, two bytes (normal size of a character in most of the systems) are filled with the values that need to be passed. Once control jumps to the new function foo2, and you use the values (passed as parameters) in the function, they are retrieved from the stack and used.

There are two parameter passing techniques in use,
 * 1. Pass by Value
 * 2. Pass by Reference

Parameter passing techniques can also use
 * right-to-left (C-style)
 * left-to-right (Pascal style)

On processors with lots of registers (such as the ARM and the Sparc), the standard calling convention puts *all* the parameters (and even the return address) in registers.

On processors with inadequate numbers of registers (such as the 80x86 and the M8C), all calling conventions are forced to put at least some parameters on the stack or elsewhere in RAM.

Some calling conventions allow "re-entrant code".

Pass by Value
With pass-by-value, a copy of the actual value (the literal content) is passed. For example, if you have a function that accepts two characters like

and you invoke this function as follows

then the program pushes a copy of the ASCII values of 'A' and 'B' (65 and 66 respectively) onto the stack before the function foo is called. You can see that there is no mention of variables 'a' or 'b' in the function foo. So, any changes that you make to those two values in foo will not affect the values of a and b in the calling function.

Pass by Reference

 * Imagine a situation where you have to pass a large amount of data to a function and apply the modifications, done in that function, to the original variables. An example of such a situation might be a function that converts a string with lower case alphabets to upper case. It would be an unwise decision to pass the entire string (particularly if it is a big one) to the function, and when the conversion is complete, pass the entire result back to the calling function. Here we pass the address of the variable to the function. This has two advantages, one, you don't have to pass huge data, thereby saving execution time and two, you can work on the data right away so that by the end of the function, the data in the calling function is already modified.

 * But remember, any change you make to the variable passed by reference will result in the original variable getting modified. If that's not what you wanted, then you must manually copy the variable before calling the function.

80x86 / Pentium
Prior to the current generation of 32bit and 64 bit based processors, the 80x86 architecture used a complex segmented memory model (also referred to as real mode). For most purposes this will not not be encountered unless writing exceptionally low level code to interface directly with hardware or peripheral chips.

Modern code is typically written to support the 'protected mode' in which the memory space can for most purposes be considered to be flat.

The information below related to calling conventions in the protected mode.

CDECL
In the CDECL calling convention the following holds:
 * Arguments are passed on the stack in Right-to-Left order, and return values are passed in eax.
 * The calling function cleans the stack. This allows CDECL functions to have variable-length argument lists (aka variadic functions). For this reason the number of arguments is not appended to the name of the function by the compiler, and the assembler and the linker are therefore unable to determine if an incorrect number of arguments is used.

Variadic functions usually have special entry code, generated by the va_start, va_arg C pseudo-functions.

Consider the following C instructions:

and the following function call:

These would produce the following assembly listings, respectively:

and

When translated to assembly code, CDECL functions are almost always prepended with an underscore (that's why all previous examples have used "_" in the assembly code).

STDCALL
STDCALL, also known as "WINAPI" (and a few other names, depending on where you are reading it) is used almost exclusively by Microsoft as the standard calling convention for the Win32 API. Since STDCALL is strictly defined by Microsoft, all compilers that implement it do it the same way.

 * STDCALL passes arguments right-to-left, and returns the value in eax. (The Microsoft documentation erroneously claims that arguments are passed left-to-right, but this is not the case.)
 * The called function cleans the stack, unlike CDECL. This means that STDCALL doesn't allow variable-length argument lists.

Consider the following C function:

and the calling instruction:

These will produce the following respective assembly code fragments:

and

There are a few important points to note here:

 * 1) In the function body, the ret instruction has an (optional) argument that indicates how many bytes to pop off the stack when the function returns.
 * 2) STDCALL functions are name-decorated with a leading underscore, followed by an @, and then the number (in bytes) of arguments passed on the stack. This number will always be a multiple of 4, on a 32-bit aligned machine.

FASTCALL
The FASTCALL calling convention is not completely standard across all compilers, so it should be used with caution. In FASTCALL, the first 2 or 3 32-bit (or smaller) arguments are passed in registers, with the most commonly used registers being edx, eax, and ecx. Additional arguments, or arguments larger than 4-bytes are passed on the stack, often in Right-to-Left order (similar to CDECL). The calling function most frequently is responsible for cleaning the stack, if needed.

Because of the ambiguities, it is recommended that FASTCALL be used only in situations with 1, 2, or 3 32-bit arguments, where speed is essential.

The following C function:

and the following C function call:

Will produce the following assembly code fragments for the called, and the calling functions, respectively:

and

The name decoration for FASTCALL prepends an @ to the function name, and follows the function name with @x, where x is the number (in bytes) of arguments passed to the function.

Many compilers still produce a stack frame for FASTCALL functions, especially in situations where the FASTCALL function itself calls another subroutine. However, if a FASTCALL function doesn't need a stack frame, optimizing compilers are free to omit it.

ARM
Practically everyone using ARM processors uses the standard calling convention. This makes mixed C and ARM assembly programming fairly easy, compared to other processors. The simplest entry and exit sequence for Thumb functions is:

AVR
What registers are used by the C compiler?

Data types
char is 8 bits, int is 16 bits, long is 32 bits, long long is 64 bits, float and double are 32 bits (this is the only supported floating point format), pointers are 16 bits (function pointers are word addresses, to allow addressing the whole 128K program memory space on the ATmega devices with > 64 KB of flash ROM). There is a -mint8 option (see Options for the C compiler avr-gcc) to make int 8 bits, but that is not supported by avr-libc and violates C standards (int must be at least 16 bits). It may be removed in a future release.

Call-used registers (r18-r27, r30-r31)
May be allocated by GNU GCC for local data. You may use them freely in assembler subroutines. Calling C subroutines can clobber any of them - the caller is responsible for saving and restoring.

Call-saved registers (r2-r17, r28-r29)
May be allocated by GNU GCC for local data. Calling C subroutines leaves them unchanged. Assembler subroutines are responsible for saving and restoring these registers, if changed. r29:r28 (Y pointer) is used as a frame pointer (points to local data on stack) if necessary. The requirement for the callee to save/preserve the contents of these registers even applies in situations where the compiler assigns them for argument passing.

Fixed registers (r0, r1)
Never allocated by GNU GCC for local data, but often used for fixed purposes:

r0 - temporary register, can be clobbered by any C code (except interrupt handlers which save it), may be used to remember something for a while within one piece of assembler code

r1 - assumed to be always zero in any C code, may be used to remember something for a while within one piece of assembler code, but must then be cleared after use (clr r1). This includes any use of the [f]mul[s[u]] instructions, which return their result in r1:r0. Interrupt handlers save and clear r1 on entry, and restore r1 on exit (in case it was non-zero).

Function call conventions
Arguments - allocated left to right, r25 to r8. All arguments are aligned to start in even-numbered registers (odd-sized arguments, including char, have one free register above them). This allows making better use of the movw instruction on the enhanced core.

If too many, those that don't fit are passed on the stack.

Return values: 8-bit in r24 (not r25!), 16-bit in r25:r24, up to 32 bits in r22-r25, up to 64 bits in r18-r25. 8-bit return values are zero/sign-extended to 16 bits by the caller (unsigned char is more efficient than signed char - just clr r25). Arguments to functions with variable argument lists (printf etc.) are all passed on stack, and char is extended to int.

Warning: There was no such alignment before 2000-07-01, including the old patches for gcc-2.95.2. Check your old assembler subroutines, and adjust them accordingly.

Microchip PIC
Unfortunately, several different (incompatible) calling conventions are used in writing programs for the Microchip PIC.

And several "features" of the PIC architecture make most subroutine calls require several instructions—much more verbose than the single instruction on many other processors.

The calling convention must deal with:
 * The "paged" flash program memory architecture
 * limitations on the hardware stack (perhaps by simulating a stack in software)
 * the "paged" RAM data memory architecture
 * making sure a subroutine call by an interrupt routine doesn't scramble information needed after the interrupt returns to the main loop.

Sparc
The Sparc has special hardware that supports a nice calling convention:

A "register window" ...


text:
Blender 3D: Noob to Pro/Advanced Tutorials/Advanced Animation/Guided tour/Armature/object

The Armature Object
Armature Object is like any other object type:

Try it now: add an armature to your scene: SPACEKEY --> Add --> Armature.
 * It has a center, a position, a rotation and a scale factor.
 * It can be edited.
 * It can be linked to other scenes, and the same armature data can be reused on multiple objects.
 * All animation you do in object mode is only working on the object, not the armature's contents like bones.

Or you can press the Shift + A keys, and select single bone from the armature menu.

When you add a new armature, you'll enter editmode automatically. To switch between modes, use the TABKEY or the dropdown menu in the Header of the 3Dview window (This might not be the case with blender 2.49b, you won't enter edit mode in that version):

The Edit Panel When in Object Mode
This is how the edit panel looks after you have added a new armature and switched to object mode (TABKEY):

 * Link and Materials panel:
 * The AR: field let you rename your armature Datablock. The dropdown is a quick way to select which Armature datablock you want to connect to this armature. You can keep more than one version for the same character. Useful when you have a special move to achieve in a shot, you can turn on an armature for a special purpose.
 * The F button is an option to assign a Fake user to the Armature. Again if you have more than one armature for your character, it's a good idea to turn the Fake on, because if your armature datablock is not used (linked) it's not going to be saved in your .blend files. You can always do batch Fake-assignment of armatures by opening the Datablock browser (SHIFT-F4KEY), go in Armature datablock, select all the armatures you want to keep, and Press the FKEY.
 * The OB: field is just to Rename your armature Object to something more cool and useful than Armature... Armature.001...

 * Armature panel:
 * Editing Options:
 * X-Axis Mirror Edit: Not really useful now, it's more of an editmode option. This feature tells Blender you want to replicate all of your bones on one part of the Armature to the other. It's a clean way to just do half the job ;). The axis of mirroring is X so left<-->right in frontview (NUMPAD_1KEY) and the center is the center of the armature object. We will see this feature in detail in the next page.
 * X-Ray: This option will let you see the armature through anything in the scene, solid or not. It's useful to see where your bones are in your character so you can select them.
 * Automatic IK is a Posemode option. It lets you pose a chain of bones as if the bone you were holding was an ik target. More info in Posemode page.
 * Display Options: These options give you the chance to visualise your bones in various ways. Also note that there is some specific options and features regarding the display mode you're in.
 * Octahedron: This is the default view. Nothing exciting except you have a good idea of the rolling of the bones.[[Image:Octahedron_bone.jpg]]
 * Stick: This display mode is really useful when you have a lot of bones in your view. It lets you "unclutter" the screen a bit. It draws the bones as tiny sticks.[[File:Stick bone.jpg]]
 * B-Bones: It's more a feature than a display mode. This is only useful to visualise the effect you get when you activate the B-bones (Bézier-Bones). Each bone acts like a curve handle and lets you get extremely curvy poses. This will be exposed in the following pages.[[Image:Bbones.jpg]]
 * Envelope: Again it's more a feature than a display mode. But in this case the visualisation will be useful to tweak your rig later. Envelope lets you easily tell which part of your character this bone will animate and it's visually possible to change the zone of influence exclusively in this display mode. The zone is only visible in Editmode or Posemode though.[[Image:Env_bone.jpg]]
 * Draw Axes: To draw the axes on each bone of the armature when you are in Editmode or Posemode. Useful when you want to know where you are and which axis to use in a constraint for example. Mental note: Y is up, Z is depth and X is side, contrary to object for which Z is up, Y is depth and X is side.[[Image:Axis_drawing.jpg]]
 * Draw names: This lets you see names of bones whatever the mode you are in. It's useful again to edit your armature, create parent dependencies or add constraints. [[Image:Name_drawing.jpg]]
 * Ghost: This option lets you see a ghost of the armature in frames behind and over the current time. This is only working when you have an action linked to the armature, as we will see later.
 * Step: This option lets you choose the frames interval between ghost instances.
 * Deform options:
 * Vertex Groups & Envelope: These two toggles let you choose if you want the armature to deform your character using the Vertex Groups and/or the Envelopes. We will see that later.
 * Rest position: This will bring the character back to factory default (item as Editmode), and no actions will be applied to the armature so you can easily edit it in the middle of an animation.
 * Delay Deform: This was useful before as the old system was very slow. What it does is when you do a manipulation to the rig, it waits until you finish to update the view. Can still be useful though.

Extra Practice
This YouTube tutorial might also help: Link The short tutorial might be a help Link 2


text:
Embedded Systems/Real-Time Operating Systems

A Real-Time Operating System (RTOS) is a computing environment that reacts to input within a specific time period. A real-time deadline can be so small that system reaction appears instantaneous. The term real-time computing has also been used, however, to describe "slow real-time" output that has a longer, but fixed, time limit.

Learning the difference between real-time and standard operating systems is as easy as imagining yourself in a computer game. Each of the actions you take in the game is like a program running in that environment. A game that has a real-time operating system for its environment can feel like an extension of your body because you can count on a specific "lag time:" the time between your request for action and the computer's noticeable execution of your request. A standard operating system, however, may feel disjointed because the lag time is unreliable. To achieve time reliability, real-time programs and their operating system environment must prioritize deadline actualization before anything else. In the gaming example, this might result in dropped frames or lower visual quality when reaction time and visual effects conflict.

Methods
An operating system is considered real-time if it invariably enables its programs to perform tasks within specific time constraints, usually those expected by the user. To meet this definition, some or all of the following methods are employed:
 * The RTOS performs few tasks, thus ensuring that the tasks will always be executed before the deadline
 * The RTOS drops or reduces certain functions when they cannot be executed within the time constraints ("load shedding")
 * The RTOS monitors input consistently and in a timely manner
 * The RTOS monitors resources and can interrupt background processes as needed to ensure real-time execution
 * The RTOS anticipates potential requests and frees enough of the system to allow timely reaction to the user's request
 * The RTOS keeps track of how much of each resource (CPU time per timeslice, RAM, communications bandwidth, etc.) might possibly be used in the worst-case by the currently-running tasks, and refuses to accept a new task unless it "fits" in the remaining un-allocated resources.

Chapters in this section will discuss how an RTOS works, some general methods for working with an RTOS, and a few popular RTOSes. Finally, in some later chapters, we will discuss how to write your own RTOS

Objectives
An RTOS must respond in a timely manner to changes, but that does not necessarily mean that an RTOS can handle a large throughput of data. In fact in an RTOS, small response times are valued much higher than computing power, or data speed. Sometimes an RTOS will even need to drop data to ensure that it meets its strict deadlines. In essence, that provides us with a perfect definition: an RTOS is an operating system designed to meet strict deadlines. Beyond that definition, there are few requirements as to what an RTOS must be, or what features it must have. Some RTOS implementations are very complete and very robust, while other implementations are very simple, and suited for only one particular purpose.

An RTOS may be either event-driven or time-sharing. An event-driven RTOS is a system that changes state only in response to an incoming event. A time-sharing RTOS is a system that changes state as a function of time.

The Fundamentals
To most people, embedded systems are not recognizable as computers. Instead, they are hidden inside everyday objects that surround us and help us in our lives. Embedded systems typically do not interface with the outside world through familiar personal computer interface devices such as a mouse, keyboard and graphic user interface. Instead, they interface with the outside world through unusual interfaces such as sensors, actuators and specialized communication links. Real-time and embedded systems operate in constrained environments in which computer memory and processing power are limited. They often need to provide their services within strict time deadlines to their users and to the surrounding world. It is these memory, speed and timing constraints that dictate the use of real-time operating systems in embedded software.

Real-Time Kernel
The heart of a real-time OS (and the heart of every OS, for that matter) is the kernel. A kernel is the central core of an operating system, and it takes care of all the OS jobs:

 * 1) Booting
 * 2) Task Scheduling
 * 3) Standard Function Libraries

Now, we will talk about booting and bootloaders later, and we will also devote several chapters to task scheduling. So we should mention at least one thing about standard function libraries: In an embedded system, there is rarely enough memory (if any) to maintain a large function library. If functions are going to be included, they must be small, and important.

In an embedded system, frequently the kernel will boot the system, initialize the ports and the global data items. Then, it will start the scheduler and instantiate any hardware timers that need to be started. After all that, the Kernel basically gets dumped out of memory (except for the library functions, if any), and the scheduler will start running the child tasks.

Basic Kernel Services
In the discussion below, we will focus on the "kernel" — the part of an operating system that provides the most basic services to application software running on a processor. The "kernel" of a real-time operating system ("RTOS") provides an "abstraction layer" that hides from application software the hardware details of the processor (or set of processors) upon which the application software will run.

For further reading

 * Operating System Design
 * RTEMS for Embedded Software Developers
 * Embedded Control Systems Design/Operating systems
 * ../Atmel AVR/Operating systems and task managers/
 * "Operating systems on the rise" by Jim Turley, Embedded Systems Design 2006-06-21. Survey results show that about 3/4 of all embedded system projects use some kind of an operating system. About 1/4 of all embedded system projects use no operating system at all (presumably using a Embedded Systems/Super Loop Architecture instead).

See Embedded Systems/Common RTOS for a list of common real-time operating systems.


text:
Embedded Systems/Memory

On an Embedded System, memory is at a premium. Some chips, particularly embedded VLSI chips, and low-end microprocessors may only have a small amount of RAM "on board" (built directly into the chip), and therefore their memory is not expandable. Other embedded systems have a certain amount of memory, and have no means to expand. In addition to RAM, some embedded systems have some non-volatile memory, in the form of miniature magnetic disks, FLASH memory expansions, or even various 3rd-party memory card expansions. Keep in mind however, that a memory upgrade on an embedded system may cost more than the entire system itself. An embedded systems programmer, therefore, needs to be very much aware of the memory available, and the memory needed to complete a task.

Memory is frequently broken up into a number of different regions that are set aside for particular purposes.

Addressable Areas
There are typically 4 distinct addressable areas, each one implemented with a different technology:

 * Program memory (which holds the programs you write), often called ROM (although most developers prefer to use chips that actually implement this with Flash). While your program is running, it is impossible to change any of the data in program memory. But at least when the power comes back on, it's all still there.
 * RAM, which holds the variables and stack. (Initial values for variables are copied from ROM). Forgets everything when power is lost.
 * EEPROM. Used kind of like the hard drive in a personal computer, to store settings that might change occasionally, and that need to be remembered next time it starts up.
 * I/O. This is really the entire point of a microcontroller.

Many popular microcontrollers (including the 8051, the Atmel AVR, the Microchip PIC, the Cypress PSoC) have a "Harvard architecture", meaning that programs can only execute out of "ROM". You can copy bytes from ROM (or elsewhere) into RAM, but it's physically impossible to jump or call such "code" in RAM. This is exactly the opposite of the situation on desktop computers, where the code you write cannot be executed until after it is copied into RAM.

A few popular microcontrollers (such as the 68HC11 and 68HC12 and ...) have a unified address space (a "von Neumann architecture"). You can jump or call code anywhere (although jumping to an address in I/O space is almost certainly not what you really wanted to do).

Paging and Banking
Often software applications grow and grow. Ancient processors (such as the 8085 used on the Mars rover Sojourner) with 16 bit address registers can directly access a maximum of 65 536 locations—however, systems using these processors often have much more physical RAM and ROM than that. They use "paging" hardware that swaps in and out "banks" of memory into the directly accessible space. Early Microchip PIC processors had 2 completely separate set of "banking registers", one for swapping in different banks of program ROM, the other for swapping in different banks of RAM.

Memory Management
All too often, programs written for embedded systems grow and grow until they exceed the available program space. There are a variety of techniques for dealing with the out-of-memory problem:
 * re-compile with the "-Os" (optimize for size) option
 * find and comment-out "dead code"
 * "refactor" repeated sections into a common subroutine
 * trade RAM space for program space.
 * put a small interpreter in "internal program memory" that loads and interprets "instructions".
 * use "instructions"—perhaps p-code or threaded code—that are more compact than directly coding it in assembly language. Or
 * place these "instructions" can be placed in EEPROM or external serial Flash that couldn't otherwise be used as program memory. Or
 * Both. This technique is often used in "stamp" style CPU modules.
 * add more memory (perhaps using a paging or banking scheme)

Most CPUs used in desktop machines have a "memory management unit" (MMU). The MMU handles virtual memory, protects regions of memory used by the OS from untrusted programs, and ...

Most embedded systems do not have a MMU. We discuss the two versions of Linux that can run on a system that does not have a MMU in Embedded Systems/Linux.

Reserved Memory
Reserved memory is memory which is reserved for some purpose like additional software installation and startup.

Segmented Memory
Old X86 processors were only 16 bit processors, and if a flat memory scheme was used, those processors would only be able to support 65 Kilobytes of memory. The system engineers behind the old 8086 and 80286 processors came up with the idea to segment memory, and use a combination of segment pointers and offset pointers to access an effective 20 bit address range, for a maximum of 1 megabyte of addressable memory.

Address = (Segment register * 16) + pointer register

New 32 bit processors allow for 4 Gigabytes of addressable memory space, and therefore the segmented memory model was all but abandoned in current 32 bit machines (although the segment registers are still used to implement paging schemes).

Memory-Mapped I/O
Memory-Mapped I/O is a mechanism by which the processor performs I/O access by using memory access techniques. This is often put into effect because the memory bus is frequently much faster than the I/O bus. Another reason that memory mapped I/O might be used is that the architecture in use does not have a separate I/O bus.

In memory mapped IO, certain range of CPU's address space is kept aside for the external peripherals. These locations can be accessed using the same instructions as used for other memory accesses. But instead, the read/writes to these addresses are interpreted as access to device rather than a location on the main memory.

A CPU may expect a particular device at a fixed location or can dynamically assign a space for it.

The way this works is that memory interfaces are often designed as a bus (a shared communications resource), where many devices are attached. These devices are usually arranged as primary and secondary devices, where a primary device can send and receive data from any of the secondary devices. A typical system would have:
 * A CPU as the primary
 * One or more RAM and/or ROM devices for program code and data storage
 * Peripheral devices for interfacing with the outside world. Examples of these might be a UART (serial communications), Display device or Input device

title: Embedded Systems/Memory


text:
Linux Guide/Network administration

You can have many possible configurations for connecting to the Internet with the Slackware Distro. The most essential part is the computer, but the most basic part is the most current Slackware Distro CDs. You can download these via FTP or HTTP, and rsync is the latest way to acquire the distros, but we won't do it that way seeing that we are just starting out here.

You should have one of two ways available to get into the Internet. It is somewhat foolish to make a guide on how to get online with Slack if we aren't assuming you have another way to connect to the Internet with another (or the same) computer. We will basically copy the way your current PC connects to the Internet with its respective Operating System (OS).

The first way is via Ethernet. This uses the 10/100/1000base-T hardware, and TCP/IP for data packets.

The second way is via Wireless. This uses the 802.11 hardware, and TCP/IP for data packets.

The third and least common today is via analog phone lines using a modem to modulate digital bits to analog datastreams. This uses the modem as the hardware, and TCP/IP for data packets linked with the PPP connection protocol.

The other ways include variations of these protocols and hardware. Such as a Cable/DSL modem connected through 10base-T ethernet to a consumer router/firewall, and translated with NAT to either/both 802.11 and/or ethernet. What this reduces down to is that the direct link from your computer to the closest Internet related device will be, ~98% of the time, an ethernet cable or an 802.11 wireless uplink.

Also included in various hardware connections are IrDA, Bluetooth, Firewire (IEEE 1394/iLINK), and several others. These are not any more "advanced," but are simply not main-stream.

title: Linux Guide/Network administration


text:
Embedded Systems/Where To Buy

This page will list some places where the reader can buy some of the hardware discussed in this book. Some of the embedded systems can be purchased for relatively cheap (some PIC microcontrollers will cost 5$ or less), and therefore the reader can purchase them for cheap and play around with them. Some of the embedded computers are relatively expensive, but these ones are very useful for home projects, because larger expensive boards will be more versatile, and will have more gadgets and gizmos to play with.

 * JK Microsystems This company has a number of good, solid embedded computers, many of which are i386 compatible. Many of these computers come with DOS preloaded, but an RTOS called "eRTOS" is available for free. Many of these computers come with ethernet extensions, so they can be used to perform simple web-based tasks (IRC bot, or simple web server, for instance).
 * Technologic Inc. This company offers many moderate to high-end microprocessors with a number of available add-ons including PCMCIA cards (for things like wireless internet cards). Many of these systems are pre-loaded with a linux distro called "TS-Linux"
 * ZWorld This webpage offers a number of embedded systems and development kits. The flagship model is called the "Rabbit Core", and is a very fast and flexible microprocessor. These core units can be incorporated into a number of different "single board computers", for maximum flexibility. RabbitCore processors are programming in a proprietary language called "Dynamic C", which is similar to standard C.
 * Rentron This webpage is basically a large catalogue for a number of different components including microcontrollers, microprocessors, transmitters, receivers, encoders, decoders, etc..
 * http://www.atmel.com This company sells a large number of different types of components, including ARM chips, an 8051-compatible chip, and a proprietary 8-bit microprocessor called the "Atmel AVR", and a 4-bit microprocessor called the "MARC4". Also sells a number of DSP modules, and controllers.
 * Embedded Planet This company offers numerous fully customizable PowerPC, XScale, ARM and MIPS based embedded computers with multiple bootloader and operating system choices.
 * YourDuino Shop - Low-cost Arduino-compatible boards, Sensors, Output Devices, Robotics, Electronics Components

title: Embedded Systems/Where To Buy


text:
Introduction to Latin American Studies

Introduction

 * Introduction for Students
 * /Teacher's Guide/

Geography

 * Introduction
 * What is Latin America?
 * A Land of Extremes
 * Virtual Field Trips and Web Links
 * Teacher's Guide

American Origins

 * Introduction
 * The First Americans
 * The Olmec
 * The Maya
 * The Toltecs
 * The Aztecs
 * The Inca
 * North American Cultures
 * Art, Music, and Literature
 * Virtual Field Trips and Web Links
 * Teacher's Guide

Conquest and Colonialism

 * Introduction
 * Gold, God, and Glory
 * Columbus: Hero or Villain?
 * Conquest of Mexico
 * Conquest of the Andes
 * American Genocide
 * American Slavery
 * Colonialism: Then and Now
 * Art, Music, and Literature
 * Virtual Field Trips and Web Links
 * Teacher's Guide

Hopes and Dreams

 * Introduction
 * Dictators and Dirty Wars
 * Poverty
 * Drugs
 * Guerrilas
 * Free Trade: American Dream?
 * Nature in Jeopardy?
 * Art, Music, and Literature of Contemporary Latin America
 * Virtual Field Trips and Web Links
 * Teacher's Guide

American Neighbors

 * Introduction
 * Al Norte
 * Amérixa
 * Coming Home: The Mexicans
 * Wetback and Green Cards: Crossing the Border
 * Cuba:Problems in America's Backyard
 * Cuban Americans
 * Puerto Ricans, Dominicans, and Central Americans
 * American Incursions
 * America Facing the Future
 * Latin Art, Music, and Literature in the United States
 * Virtual Field Trips and Web Links
 * Teacher's Guide

Appendices

 * /Authors and Contributors/

title: Introduction to Latin American Studies


text:
Introduction to Latin American Studies/Contents

Appendices
  Authors and Contributors

Notes for Contributors
This is a wiki textbook -- feel free to edit it, update it, correct it, and otherwise increase its teaching potential. To find out more about wikis, see the Wikipedia main page.


text:
Introduction to Latin American Studies/Authors and Contributors

Original Organization & Compilation

 * Jonathan Loomis
 * 2001: BA Spanish/Latin American Studies & Secondary Education - American University, Washington, DC
 * 2001-2003: Teacher - Wilson Senior High School, Washington, DC
 * 2003-2005: Teacher - Dole Middle School, Honolulu, HI
 * 2005- : Teacher - Washington Middle School, Honolulu, HI