Linux System Call Table
The following table lists the system calls for the Linux 2.2 kernel. It could also be thought of as an API for the interface between user space and kernel space. My motivation for making this table was to make programming in assembly language easier when using only system calls and not the C library (for more information on this topic, go to http://www.linuxassembly.org). On the left are the numbers of the system calls. This number will be put in register %eax. On the right of the table are the types of values to be put into the remaining registers before calling the software interrupt 'int 0x80'. After each syscall, an integer is returned in %eax.
For convenience, the kernel source file where each system call is located is linked to in the column labelled "Source". In order to use the hyperlinks, you must first copy this page to your own machine because the links take you directly to the source code on your system. You must have the kernel source installed (or linked from) under '/usr/src/linux' for this to work.
%eax Name Source %ebx %ecx %edx %esx %edi
1 sys_exit kernel/exit.c int - - - -
2 sys_fork arch/i386/kernel/process.c struct pt_regs - - - -
3 sys_read fs/read_write.c unsigned int char * size_t - -
4 sys_write fs/read_write.c unsigned int const char * size_t - -
5 sys_open fs/open.c const char * int int - -
6 sys_close fs/open.c unsigned int - - - -
7 sys_waitpid kernel/exit.c pid_t unsigned int * int - -
8 sys_creat fs/open.c const char * int - - -
9 sys_link fs/namei.c const char * const char * - - -
10 sys_unlink fs/namei.c const char * - - - -
11 sys_execve arch/i386/kernel/process.c struct pt_regs - - - -
12 sys_chdir fs/open.c const char * - - - -
13 sys_time kernel/time.c int * - - - -
14 sys_mknod fs/namei.c const char * int dev_t - -
15 sys_chmod fs/open.c const char * mode_t - - -
16 sys_lchown fs/open.c const char * uid_t gid_t - -
18 sys_stat fs/stat.c char * struct __old_kernel_stat * - - -
19 sys_lseek fs/read_write.c unsigned int off_t unsigned int - -
20 sys_getpid kernel/sched.c - - - - -
21 sys_mount fs/super.c char * char * char * - -
22 sys_oldumount fs/super.c char * - - - -
23 sys_setuid kernel/sys.c uid_t - - - -
24 sys_getuid kernel/sched.c - - - - -
25 sys_stime kernel/time.c int * - - - -
26 sys_ptrace arch/i386/kernel/ptrace.c long long long long -
27 sys_alarm kernel/sched.c unsigned int - - - -
28 sys_fstat fs/stat.c unsigned int struct __old_kernel_stat * - - -
29 sys_pause arch/i386/kernel/sys_i386.c - - - - -
30 sys_utime fs/open.c char * struct utimbuf * - - -
33 sys_access fs/open.c const char * int - - -
34 sys_nice kernel/sched.c int - - - -
36 sys_sync fs/buffer.c - - - - -
37 sys_kill kernel/signal.c int int - - -
38 sys_rename fs/namei.c const char * const char * - - -
39 sys_mkdir fs/namei.c const char * int - - -
40 sys_rmdir fs/namei.c const char * - - - -
41 sys_dup fs/fcntl.c unsigned int - - - -
42 sys_pipe arch/i386/kernel/sys_i386.c unsigned long * - - - -
43 sys_times kernel/sys.c struct tms * - - - -
45 sys_brk mm/mmap.c unsigned long - - - -
46 sys_setgid kernel/sys.c gid_t - - - -
47 sys_getgid kernel/sched.c - - - - -
48 sys_signal kernel/signal.c int __sighandler_t - - -
49 sys_geteuid kernel/sched.c - - - - -
50 sys_getegid kernel/sched.c - - - - -
51 sys_acct kernel/acct.c const char * - - - -
52 sys_umount fs/super.c char * int - - -
54 sys_ioctl fs/ioctl.c unsigned int unsigned int unsigned long - -
55 sys_fcntl fs/fcntl.c unsigned int unsigned int unsigned long - -
57 sys_setpgid kernel/sys.c pid_t pid_t - - -
59 sys_olduname arch/i386/kernel/sys_i386.c struct oldold_utsname * - - - -
60 sys_umask kernel/sys.c int - - - -
61 sys_chroot fs/open.c const char * - - - -
62 sys_ustat fs/super.c dev_t struct ustat * - - -
63 sys_dup2 fs/fcntl.c unsigned int unsigned int - - -
64 sys_getppid kernel/sched.c - - - - -
65 sys_getpgrp kernel/sys.c - - - - -
66 sys_setsid kernel/sys.c - - - - -
67 sys_sigaction arch/i386/kernel/signal.c int const struct old_sigaction * struct old_sigaction * - -
68 sys_sgetmask kernel/signal.c - - - - -
69 sys_ssetmask kernel/signal.c int - - - -
70 sys_setreuid kernel/sys.c uid_t uid_t - - -
71 sys_setregid kernel/sys.c gid_t gid_t - - -
72 sys_sigsuspend arch/i386/kernel/signal.c int int old_sigset_t - -
73 sys_sigpending kernel/signal.c old_sigset_t * - - - -
74 sys_sethostname kernel/sys.c char * int - - -
75 sys_setrlimit kernel/sys.c unsigned int struct rlimit * - - -
76 sys_getrlimit kernel/sys.c unsigned int struct rlimit * - - -
77 sys_getrusage kernel/sys.c int struct rusage * - - -
78 sys_gettimeofday kernel/time.c struct timeval * struct timezone * - - -
79 sys_settimeofday kernel/time.c struct timeval * struct timezone * - - -
80 sys_getgroups kernel/sys.c int gid_t * - - -
81 sys_setgroups kernel/sys.c int gid_t * - - -
82 old_select arch/i386/kernel/sys_i386.c struct sel_arg_struct * - - - -
83 sys_symlink fs/namei.c const char * const char * - - -
84 sys_lstat fs/stat.c char * struct __old_kernel_stat * - - -
85 sys_readlink fs/stat.c const char * char * int - -
86 sys_uselib fs/exec.c const char * - - - -
87 sys_swapon mm/swapfile.c const char * int - - -
88 sys_reboot kernel/sys.c int int int void * -
89 old_readdir fs/readdir.c unsigned int void * unsigned int - -
90 old_mmap arch/i386/kernel/sys_i386.c struct mmap_arg_struct * - - - -
91 sys_munmap mm/mmap.c unsigned long size_t - - -
92 sys_truncate fs/open.c const char * unsigned long - - -
93 sys_ftruncate fs/open.c unsigned int unsigned long - - -
94 sys_fchmod fs/open.c unsigned int mode_t - - -
95 sys_fchown fs/open.c unsigned int uid_t gid_t - -
96 sys_getpriority kernel/sys.c int int - - -
97 sys_setpriority kernel/sys.c int int int - -
99 sys_statfs fs/open.c const char * struct statfs * - - -
100 sys_fstatfs fs/open.c unsigned int struct statfs * - - -
101 sys_ioperm arch/i386/kernel/ioport.c unsigned long unsigned long int - -
102 sys_socketcall net/socket.c int unsigned long * - - -
103 sys_syslog kernel/printk.c int char * int - -
104 sys_setitimer kernel/itimer.c int struct itimerval * struct itimerval * - -
105 sys_getitimer kernel/itimer.c int struct itimerval * - - -
106 sys_newstat fs/stat.c char * struct stat * - - -
107 sys_newlstat fs/stat.c char * struct stat * - - -
108 sys_newfstat fs/stat.c unsigned int struct stat * - - -
109 sys_uname arch/i386/kernel/sys_i386.c struct old_utsname * - - - -
110 sys_iopl arch/i386/kernel/ioport.c unsigned long - - - -
111 sys_vhangup fs/open.c - - - - -
112 sys_idle arch/i386/kernel/process.c - - - - -
113 sys_vm86old arch/i386/kernel/vm86.c unsigned long struct vm86plus_struct * - - -
114 sys_wait4 kernel/exit.c pid_t unsigned long * int options struct rusage * -
115 sys_swapoff mm/swapfile.c const char * - - - -
116 sys_sysinfo kernel/info.c struct sysinfo * - - - -
117 sys_ipc (*Note) arch/i386/kernel/sys_i386.c uint int int int void *
118 sys_fsync fs/buffer.c unsigned int - - - -
119 sys_sigreturn arch/i386/kernel/signal.c unsigned long - - - -
120 sys_clone arch/i386/kernel/process.c struct pt_regs - - - -
121 sys_setdomainname kernel/sys.c char * int - - -
122 sys_newuname kernel/sys.c struct new_utsname * - - - -
123 sys_modify_ldt arch/i386/kernel/ldt.c int void * unsigned long - -
124 sys_adjtimex kernel/time.c struct timex * - - - -
125 sys_mprotect mm/mprotect.c unsigned long size_t unsigned long - -
126 sys_sigprocmask kernel/signal.c int old_sigset_t * old_sigset_t * - -
127 sys_create_module kernel/module.c const char * size_t - - -
128 sys_init_module kernel/module.c const char * struct module * - - -
129 sys_delete_module kernel/module.c const char * - - - -
130 sys_get_kernel_syms kernel/module.c struct kernel_sym * - - - -
131 sys_quotactl fs/dquot.c int const char * int caddr_t -
132 sys_getpgid kernel/sys.c pid_t - - - -
133 sys_fchdir fs/open.c unsigned int - - - -
134 sys_bdflush fs/buffer.c int long - - -
135 sys_sysfs fs/super.c int unsigned long unsigned long - -
136 sys_personality kernel/exec_domain.c unsigned long - - - -
138 sys_setfsuid kernel/sys.c uid_t - - - -
139 sys_setfsgid kernel/sys.c gid_t - - - -
140 sys_llseek fs/read_write.c unsigned int unsigned long unsigned long loff_t * unsigned int
141 sys_getdents fs/readdir.c unsigned int void * unsigned int - -
142 sys_select fs/select.c int fd_set * fd_set * fd_set * struct timeval *
143 sys_flock fs/locks.c unsigned int unsigned int - - -
144 sys_msync mm/filemap.c unsigned long size_t int - -
145 sys_readv fs/read_write.c unsigned long const struct iovec * unsigned long - -
146 sys_writev fs/read_write.c unsigned long const struct iovec * unsigned long - -
147 sys_getsid kernel/sys.c pid_t - - - -
148 sys_fdatasync fs/buffer.c unsigned int - - - -
149 sys_sysctl kernel/sysctl.c struct __sysctl_args * - - - -
150 sys_mlock mm/mlock.c unsigned long size_t - - -
151 sys_munlock mm/mlock.c unsigned long size_t - - -
152 sys_mlockall mm/mlock.c int - - - -
153 sys_munlockall mm/mlock.c - - - - -
154 sys_sched_setparam kernel/sched.c pid_t struct sched_param * - - -
155 sys_sched_getparam kernel/sched.c pid_t struct sched_param * - - -
156 sys_sched_setscheduler kernel/sched.c pid_t int struct sched_param * - -
157 sys_sched_getscheduler kernel/sched.c pid_t - - - -
158 sys_sched_yield kernel/sched.c - - - - -
159 sys_sched_get_priority_max kernel/sched.c int - - - -
160 sys_sched_get_priority_min kernel/sched.c int - - - -
161 sys_sched_rr_get_interval kernel/sched.c pid_t struct timespec * - - -
162 sys_nanosleep kernel/sched.c struct timespec * struct timespec * - - -
163 sys_mremap mm/mremap.c unsigned long unsigned long unsigned long unsigned long -
164 sys_setresuid kernel/sys.c uid_t uid_t uid_t - -
165 sys_getresuid kernel/sys.c uid_t * uid_t * uid_t * - -
166 sys_vm86 arch/i386/kernel/vm86.c struct vm86_struct * - - - -
167 sys_query_module kernel/module.c const char * int char * size_t size_t *
168 sys_poll fs/select.c struct pollfd * unsigned int long - -
169 sys_nfsservctl fs/filesystems.c int void * void * - -
170 sys_setresgid kernel/sys.c gid_t gid_t gid_t - -
171 sys_getresgid kernel/sys.c gid_t * gid_t * gid_t * - -
172 sys_prctl kernel/sys.c int unsigned long unsigned long unsigned long unsigned long
173 sys_rt_sigreturn arch/i386/kernel/signal.c unsigned long - - - -
174 sys_rt_sigaction kernel/signal.c int const struct sigaction * struct sigaction * size_t -
175 sys_rt_sigprocmask kernel/signal.c int sigset_t * sigset_t * size_t -
176 sys_rt_sigpending kernel/signal.c sigset_t * size_t - - -
177 sys_rt_sigtimedwait kernel/signal.c const sigset_t * siginfo_t * const struct timespec * size_t -
178 sys_rt_sigqueueinfo kernel/signal.c int int siginfo_t * - -
179 sys_rt_sigsuspend arch/i386/kernel/signal.c sigset_t * size_t - - -
180 sys_pread fs/read_write.c unsigned int char * size_t loff_t -
181 sys_pwrite fs/read_write.c unsigned int const char * size_t loff_t -
182 sys_chown fs/open.c const char * uid_t gid_t - -
183 sys_getcwd fs/dcache.c char * unsigned long - - -
184 sys_capget kernel/capability.c cap_user_header_t cap_user_data_t - - -
185 sys_capset kernel/capability.c cap_user_header_t const cap_user_data_t - - -
186 sys_sigaltstack arch/i386/kernel/signal.c const stack_t * stack_t * - - -
187 sys_sendfile mm/filemap.c int int off_t * size_t -
190 sys_vfork arch/i386/kernel/process.c struct pt_regs - - - -
Note for sys_ipc (117): this syscall takes six arguments, so it can't fit into the five registers %ebx - %edi; the last parameter (not shown) is of type 'long'. This syscall requires a special call method where a pointer is put in %ebx which points to an array containing the six arguments.
I will now explain exactly where in the kernel source that I got the information in the table above. I do this because 1) changes in the source are bound to happen, 2) you might be curious, or 3) I might've made an error.
System Call Numbers
For the numbers of the syscalls, look in arch/i386/kernel/entry.S for sys_call_table. The syscall numbers are offsets into that table. Several spots in the table are occupied by the syscall sys_ni_syscall. This is a placeholder that either replaces an obsolete syscall or reserves a spot for future syscalls.
Incidentally, the system calls are called from the function system_call in the same file; in particular, they are called with the assembly instruction 'call *SYMBOL_NAME(sys_call_table)(,%eax,4)'. The part '*SYMBOL_NAME(sys_call_table)' just gets replaced by a symbol name in sys_call_table. SYMBOL_NAME is a macro defined in include/linux/linkage.h, and it just replaces itself with its argument.
Typedefs
Here are the typedef declarations in the prototypes above:
atomic_t include/asm/atomic.h:
#ifdef __SMP__
typedef struct { volatile int counter; } atomic_t;
#else
typedef struct { int counter; } atomic_t;
#endif
caddr_t include/asm/posix_types.h:typedef char * __kernel_caddr_t;
include/linux/types.h:typedef __kernel_caddr_t caddr_t;
cap_user_header_t include/linux/capability.h:
typedef struct __user_cap_header_struct {
__u32 version;
int pid;
} *cap_user_header_t;
cap_user_data_t include/linux/capability.h:
typedef struct __user_cap_data_struct {
__u32 effective;
__u32 permitted;
__u32 inheritable;
} *cap_user_data_t;
clock_t include/asm/posix_types.h:typedef long __kernel_clock_t;
include/linux/types.h:typedef __kernel_clock_t clock_t;
dev_t include/asm/posix_types.h:typedef unsigned short __kernel_dev_t;
include/linux/types.h:typedef __kernel_dev_t dev_t;
fdset include/linux/posix_types.h
#define __FD_SETSIZE 1024
#define __NFDBITS (8 * sizeof(unsigned long))
#define __FDSET_LONGS (__FD_SETSIZE/__NFDBITS)
(==> __FDSET_LONGS == 32)
typedef struct {
unsigned long fds_bits [__FDSET_LONGS];
} __kernel_fd_set;
include/linux/types.h:typedef __kernel_fd_set fd_set;
gid_t include/asm/posix_types.h:typedef unsigned short __kernel_gid_t;
include/linux/types.h:typedef __kernel_gid_t gid_t;
__kernel_daddr_t include/asm/posix_types.h:typedef int __kernel_daddr_t;
__kernel_fsid_t include/asm/posix_types.h:
typedef struct {
int __val[2];
} __kernel_fsid_t;
__kernel_ino_t include/asm/posix_types.h:typedef unsigned long __kernel_ino_t;
__kernel_size_t include/asm/posix_types.h:typedef unsigned int __kernel_size_t;
loff_t include/asm/posix_types.h:typedef long long __kernel_loff_t;
include/linux/types.h:typedef __kernel_loff_t loff_t;
mode_t include/asm/posix_types.h:typedef unsigned short __kernel_mode_t;
include/linux/types.h:typedef __kernel_mode_t mode_t;
off_t include/asm/posix_types.h:typedef long __kernel_off_t; include/linux/types.h:typedef __kernel_off_t off_t;
old_sigset_t include/asm/signal.h:typedef unsigned long old_sigset_t;
pid_t include/asm/posix_types.h:typedef int __kernel_pid_t;
include/linux/types.h:typedef __kernel_pid_t pid_t;
__sighandler_t include/asm/signal.h:typedef void (*__sighandler_t)(int);
siginfo_t include/asm/siginfo.h:
#define SI_MAX_SIZE 128
#define SI_PAD_SIZE ((SI_MAX_SIZE/sizeof(int)) - 3)
(==> SI_PAD_SIZE == 29)
typedef struct siginfo {
int si_signo;
int si_errno;
int si_code;
union {
int _pad[SI_PAD_SIZE];
/* kill() */
struct {
pid_t _pid; /* sender's pid */
uid_t _uid; /* sender's uid */
} _kill;
/* POSIX.1b timers */
struct {
unsigned int _timer1;
unsigned int _timer2;
} _timer;
/* POSIX.1b signals */
struct {
pid_t _pid; /* sender's pid */
uid_t _uid; /* sender's uid */
sigval_t _sigval;
} _rt;
/* SIGCHLD */
struct {
pid_t _pid; /* which child */
uid_t _uid; /* sender's uid */
int _status; /* exit code */
clock_t _utime;
clock_t _stime;
} _sigchld;
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
struct {
void *_addr; /* faulting insn/memory ref. */
} _sigfault;
/* SIGPOLL */
struct {
int _band; /* POLL_IN, POLL_OUT, POLL_MSG */
int _fd;
} _sigpoll;
} _sifields;
} siginfo_t;
sigset_t include/asm/signal.h:typedef unsigned long sigset_t;
size_t include/asm/posix_types.h:typedef unsigned int __kernel_size_t;
include/linux/types.h:typedef __kernel_size_t size_t;
ssize_t include/asm/posix_types.h:typedef int __kernel_ssize_t;
include/linux/types.h:typedef __kernel_ssize_t ssize_t;
stack_t include/asm/signal.h:
typedef struct sigaltstack {
void *ss_sp;
int ss_flags;
size_t ss_size;
} stack_t;
suseconds_t include/asm/posix_types.h:typedef long __kernel_suseconds_t;
include/linux/types.h:typedef __kernel_suseconds_t suseconds_t;
time_t include/asm/posix_types.h:typedef long __kernel_time_t; include/linux/types.h:typedef __kernel_time_t time_t;
uid_t include/asm/posix_types.h:typedef unsigned short __kernel_uid_t;
include/linux/types.h:typedef __kernel_uid_t uid_t;
uint include/linux/types.h:typedef unsigned int uint;
__u32 include/asm/types.h:typedef unsigned int __u32;
Struct Declarations
Here are the struct declarations for the table at the top:
exception_table_entry include/linux/module.h:
struct exception_table_entry {
unsigned long insn, fixup;
};
iovec include/linux/uio.h:
struct iovec {
void *iov_base;
__kernel_size_t iov_len; };
itimerval include/linux/time.h:
struct itimerval {
struct timeval it_interval; /* timer interval */
struct timeval it_value; /* current value */
};
kernel_sym include/linux/module.h:
struct kernel_sym {
unsigned long value;
char name[60];
};
mmap_arg_struct arch/i386/kernel/sys_i386.c:
struct mmap_arg_struct {
unsigned long addr;
unsigned long len;
unsigned long prot;
unsigned long flags;
unsigned long fd;
unsigned long offset;
};
module include/linux/module.h:
struct module {
unsigned long size_of_struct; /* sizeof(module) */
struct module *next;
const char *name;
unsigned long size;
union {
atomic_t usecount;
long pad;
} uc;
unsigned long flags; /* AUTOCLEAN et al */
unsigned nsyms;
unsigned ndeps;
struct module_symbol *syms;
struct module_ref *deps;
struct module_ref *refs;
int (*init)(void);
void (*cleanup)(void);
const struct exception_table_entry *ex_table_start;
const struct exception_table_entry *ex_table_end;
/* Members past this point are extensions to the basic
module support and are optional. Use mod_opt_member()
to examine them. */
const struct module_persist *persist_start;
const struct module_persist *persist_end;
int (*can_unload)(void);
};
module_persist include/linux/module.h:
struct module_persist; /* yes, it's empty */
module_ref include/linux/module.h:
struct module_ref {
struct module *dep; /* "parent" pointer */
struct module *ref; /* "child" pointer */
struct module_ref *next_ref;
};
module_symbol include/linux/module.h:
struct module_symbol {
unsigned long value;
const char *name;
};
new_utsname include/linux/utsname.h:
struct new_utsname {
char sysname[65];
char nodename[65];
char release[65];
char version[65];
char machine[65];
char domainname[65];
};
__old_kernel_stat include/asm/stat.h:
struct __old_kernel_stat {
unsigned short st_dev;
unsigned short st_ino;
unsigned short st_mode;
unsigned short st_nlink;
unsigned short st_uid;
unsigned short st_gid;
unsigned short st_rdev;
unsigned long st_size;
unsigned long st_atime;
unsigned long st_mtime;
unsigned long st_ctime;
};
oldold_utsname include/linux/utsname.h:
struct oldold_utsname {
char sysname[9];
char nodename[9];
char release[9];
char version[9];
char machine[9];
};
old_sigaction include/asm/signal.h:
struct old_sigaction {
__sighandler_t sa_handler;
old_sigset_t sa_mask;
unsigned long sa_flags;
void (*sa_restorer)(void);
};
old_utsname include/linux/utsname.h:
struct old_utsname {
char sysname[65];
char nodename[65];
char release[65];
char version[65];
char machine[65];
};
pollfd include/asm/poll.h:
struct pollfd {
int fd;
short events;
short revents;
};
pt_regs include/asm/ptrace.h:
struct pt_regs {
long ebx;
long ecx;
long edx;
long esi;
long edi;
long ebp;
long eax;
int xds;
int xes;
long orig_eax;
long eip;
int xcs;
long eflags;
long esp;
int xss;
};
revectored_struct include/asm/vm86.h:
struct revectored_struct {
unsigned long __map[8];
};
rlimit include/linux/resource.h:
struct rlimit {
long rlim_cur;
long rlim_max;
};
rusage include/linux/resource.h:
struct rusage {
struct timeval ru_utime; /* user time used */
struct timeval ru_stime; /* system time used */
long ru_maxrss; /* maximum resident set size */
long ru_ixrss; /* integral shared memory size */
long ru_idrss; /* integral unshared data size */
long ru_isrss; /* integral unshared stack size */
long ru_minflt; /* page reclaims */
long ru_majflt; /* page faults */
long ru_nswap; /* swaps */
long ru_inblock; /* block input operations */
long ru_oublock; /* block output operations */
long ru_msgsnd; /* messages sent */
long ru_msgrcv; /* messages received */
long ru_nsignals; /* signals received */
long ru_nvcsw; /* voluntary context switches */
long ru_nivcsw; /* involuntary '' */
};
sched_param include/linux/sched.h:
struct sched_param {
int sched_priority;
};
sel_arg_struct arch/i386/kernel/sys_i386.c:
struct sel_arg_struct {
unsigned long n;
fd_set *inp, *outp, *exp;
struct timeval *tvp;
};
sigaction include/asm/signal.h:
struct sigaction {
__sighandler_t sa_handler;
unsigned long sa_flags;
void (*sa_restorer)(void);
sigset_t sa_mask; /* mask last for extensibility */
};
stat include/asm/stat.h:
struct stat {
unsigned short st_dev;
unsigned short __pad1;
unsigned long st_ino;
unsigned short st_mode;
unsigned short st_nlink;
unsigned short st_uid;
unsigned short st_gid;
unsigned short st_rdev;
unsigned short __pad2;
unsigned long st_size;
unsigned long st_blksize;
unsigned long st_blocks;
unsigned long st_atime;
unsigned long __unused1;
unsigned long st_mtime;
unsigned long __unused2;
unsigned long st_ctime;
unsigned long __unused3;
unsigned long __unused4;
unsigned long __unused5;
statfs include/asm/statfs.h:
struct statfs {
long f_type;
long f_bsize;
long f_blocks;
long f_bfree;
long f_bavail;
long f_files;
long f_ffree;
__kernel_fsid_t f_fsid;
long f_namelen;
long f_spare[6];
};
__sysctl_args include/linux/sysctl.h
struct __sysctl_args {
int *name;
int nlen;
void *oldval;
size_t *oldlenp;
void *newval;
size_t newlen;
unsigned long __unused[4];
};
sysinfo include/linux/kernel.h:
struct sysinfo {
long uptime; /* Seconds since boot */
unsigned long loads[3]; /* 1, 5, and 15 minute load averages */
unsigned long totalram; /* Total usable main memory size */
unsigned long freeram; /* Available memory size */
unsigned long sharedram; /* Amount of shared memory */
unsigned long bufferram; /* Memory used by buffers */
unsigned long totalswap; /* Total swap space size */
unsigned long freeswap; /* swap space still available */
unsigned short procs; /* Number of current processes */
char _f[22]; /* Pads structure to 64 bytes */
};
timex include/linux/timex.h:
struct timex {
unsigned int modes; /* mode selector */
long offset; /* time offset (usec) */
long freq; /* frequency offset (scaled ppm) */
long maxerror; /* maximum error (usec) */
long esterror; /* estimated error (usec) */
int status; /* clock command/status */
long constant; /* pll time constant */
long precision; /* clock precision (usec) (read only) */
long tolerance; /* clock frequency tolerance (ppm)
* (read only)
*/
struct timeval time; /* (read only) */
long tick; /* (modified) usecs between clock ticks */
long ppsfreq; /* pps frequency (scaled ppm) (ro) */
long jitter; /* pps jitter (us) (ro) */
int shift; /* interval duration (s) (shift) (ro) */
long stabil; /* pps stability (scaled ppm) (ro) */
long jitcnt; /* jitter limit exceeded (ro) */
long calcnt; /* calibration intervals (ro) */
long errcnt; /* calibration errors (ro) */
long stbcnt; /* stability limit exceeded (ro) */
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
};
timespec include/linux/time.h:
struct timespec {
time_t tv_sec; /* seconds */
long tv_nsec; /* nanoseconds */
};
timeval include/linux/time.h:
struct timeval {
time_t tv_sec; /* seconds */
suseconds_t tv_usec; /* microseconds */
};
timezone include/linux/time.h:
struct timezone {
int tz_minuteswest; /* minutes west of Greenwich */
int tz_dsttime; /* type of dst correction */
};
tms include/linux/times.h
struct tms {
clock_t tms_utime;
clock_t tms_stime;
clock_t tms_cutime;
clock_t tms_cstime;
};
ustat include/linux/types.h:
struct ustat {
__kernel_daddr_t f_tfree;
__kernel_ino_t f_tinode;
char f_fname[6];
char f_fpack[6];
};
utimbuf include/linux/utime.h:
struct utimbuf {
time_t actime;
time_t modtime;
};
vm86plus_info_struct include/asm/vm86.h:
struct vm86plus_info_struct {
unsigned long force_return_for_pic:1;
unsigned long vm86dbg_active:1;
unsigned long vm86dbg_TFpendig:1;
unsigned long unused:28;
unsigned long is_vm86pus:1;
unsigned char vm86dbg_intxxtab[32];
};
vm86plus_struct include/asm/vm86.h:
struct vm86plus_struct {
struct vm86_regs regs;
unsigned long flags;
unsigned long screen_bitmap;
unsigned long cpu_type;
struct revectored_struct int_revectored;
struct revectored_struct int21_revectored;
struct vm86plus_info_struct vm86plus;
};
vm86_regs include/asm/vm86.h:
struct vm86_regs {
/* normal regs, with special meaning for the segment descriptors.. */
long ebx;
long ecx;
long edx;
long esi;
long edi;
long ebp;
long eax;
long __null_ds;
long __null_es;
long __null_fs;
long __null_gs;
long orig_eax;
long eip;
unsigned short cs, __csh;
long eflags;
long esp;
unsigned short ss, __ssh;
/* these are specific to v86 mode: */
unsigned short es, __esh;
unsigned short ds, __dsh;
unsigned short fs, __fsh;
unsigned short gs, __gsh;
};
vm86_struct include/asm/vm86.h:
struct vm86_struct {
struct vm86_regs regs;
unsigned long flags;
unsigned long screen_bitmap;
unsigned long cpu_type;
struct revectored_struct int_revectored;
struct revectored_struct int21_revectored;
};
-----
Cheers,
June
금요일, 9월 18, 2009
NASM Manual
Source:
http://www.posix.nl/linuxassembly/nasmdochtml/nasmdoc0.html
NASM Manual
http://www.posix.nl/linuxassembly/nasmdochtml/nasmdoc0.html
NASM Manual
The Netwide Assembler: NASM
This manual documents NASM, the Netwide Assembler: an assembler
targetting the Intel x86 series of processors, with portable source.
Chapter 1: Introduction
Section 1.1: What Is NASM?
Section 1.1.1: Why Yet Another Assembler?
Section 1.1.2: Licence Conditions
Section 1.2: Contact Information
Section 1.3: Installation
Section 1.3.1: Installing NASM under MS-DOS or Windows
Section 1.3.2: Installing NASM under Unix
Chapter 2: Running NASM
Section 2.1: NASM Command-Line Syntax
Section 2.1.1: The
Section 2.1.2: The
Section 2.1.3: The
Section 2.1.4: The
Section 2.1.5: The
Section 2.1.6: The
Section 2.1.7: The
Section 2.1.8: The
Section 2.1.9: The
Section 2.1.10: The
Section 2.1.11: The
Section 2.1.12: The
Section 2.1.13: The
Section 2.2: Quick Start for MASM Users
Section 2.2.1: NASM Is Case-Sensitive
Section 2.2.2: NASM Requires Square Brackets For Memory References
Section 2.2.3: NASM Doesn't Store Variable Types
Section 2.2.4: NASM Doesn't
Section 2.2.5: NASM Doesn't Support Memory Models
Section 2.2.6: Floating-Point Differences
Section 2.2.7: Other Differences
Chapter 3: The NASM Language
Section 3.1: Layout of a NASM Source Line
Section 3.2: Pseudo-Instructions
Section 3.2.1:
Section 3.2.2:
Section 3.2.3:
Section 3.2.4:
Section 3.2.5:
Section 3.3: Effective Addresses
Section 3.4: Constants
Section 3.4.1: Numeric Constants
Section 3.4.2: Character Constants
Section 3.4.3: String Constants
Section 3.4.4: Floating-Point Constants
Section 3.5: Expressions
Section 3.5.1:
Section 3.5.2:
Section 3.5.3:
Section 3.5.4:
Section 3.5.5:
Section 3.5.6:
Section 3.5.7: Unary Operators:
Section 3.6:
Section 3.7: Critical Expressions
Section 3.8: Local Labels
Chapter 4: The NASM Preprocessor
Section 4.1: Single-Line Macros
Section 4.1.1: The Normal Way:
Section 4.1.2: Undefining macros:
Section 4.1.3: Preprocessor Variables:
Section 4.2: Multi-Line Macros:
Section 4.2.1: Overloading Multi-Line Macros
Section 4.2.2: Macro-Local Labels
Section 4.2.3: Greedy Macro Parameters
Section 4.2.4: Default Macro Parameters
Section 4.2.5:
Section 4.2.6:
Section 4.2.7: Concatenating Macro Parameters
Section 4.2.8: Condition Codes as Macro Parameters
Section 4.2.9: Disabling Listing Expansion
Section 4.3: Conditional Assembly
Section 4.3.1:
Section 4.3.2:
Section 4.3.3:
Section 4.3.4:
Section 4.3.5:
Section 4.3.6:
Section 4.4: Preprocessor Loops:
Section 4.5: Including Other Files
Section 4.6: The Context Stack
Section 4.6.1:
Section 4.6.2: Context-Local Labels
Section 4.6.3: Context-Local Single-Line Macros
Section 4.6.4:
Section 4.6.5: Example Use of the Context Stack: Block IFs
Section 4.7: Standard Macros
Section 4.7.1:
Section 4.7.2:
Section 4.7.3:
Section 4.7.4:
Section 4.7.5:
Chapter 5: Assembler Directives
Section 5.1:
Section 5.2:
Section 5.2.1: The
Section 5.3:
Section 5.4:
Section 5.5:
Section 5.6:
Chapter 6: Output Formats
Section 6.1:
Section 6.1.1:
Section 6.1.2:
Section 6.2:
Section 6.2.1:
Section 6.2.2:
Section 6.2.3:
Section 6.2.4:
Section 6.2.5:
Section 6.2.6:
Section 6.2.7:
Section 6.2.8:
Section 6.3:
Section 6.3.1:
Section 6.4:
Section 6.5:
Section 6.5.1:
Section 6.5.2: Position-Independent Code:
Section 6.5.3:
Section 6.5.4:
Section 6.6:
Section 6.7:
Section 6.8:
Section 6.9:
Section 6.9.1: Requiring a Library: The
Section 6.10:
Chapter 7: Writing 16-bit Code (DOS, Windows 3/3.1)
Section 7.1: Producing
Section 7.1.1: Using the
Section 7.1.2: Using the
Section 7.2: Producing
Section 7.2.1: Using the
Section 7.2.2: Using the
Section 7.3: Producing
Section 7.4: Interfacing to 16-bit C Programs
Section 7.4.1: External Symbol Names
Section 7.4.2: Memory Models
Section 7.4.3: Function Definitions and Function Calls
Section 7.4.4: Accessing Data Items
Section 7.4.5:
Section 7.5: Interfacing to Borland Pascal Programs
Section 7.5.1: The Pascal Calling Convention
Section 7.5.2: Borland Pascal Segment Name Restrictions
Section 7.5.3: Using
Chapter 8: Writing 32-bit Code (Unix, Win32, DJGPP)
Section 8.1: Interfacing to 32-bit C Programs
Section 8.1.1: External Symbol Names
Section 8.1.2: Function Definitions and Function Calls
Section 8.1.3: Accessing Data Items
Section 8.1.4:
Section 8.2: Writing NetBSD/FreeBSD/OpenBSD and Linux/ELF Shared Libraries
Section 8.2.1: Obtaining the Address of the GOT
Section 8.2.2: Finding Your Local Data Items
Section 8.2.3: Finding External and Common Data Items
Section 8.2.4: Exporting Symbols to the Library User
Section 8.2.5: Calling Procedures Outside the Library
Section 8.2.6: Generating the Library File
Chapter 9: Mixing 16 and 32 Bit Code
Section 9.1: Mixed-Size Jumps
Section 9.2: Addressing Between Different-Size Segments
Section 9.3: Other Mixed-Size Instructions
Chapter 10: Troubleshooting
Section 10.1: Common Problems
Section 10.1.1: NASM Generates Inefficient Code
Section 10.1.2: My Jumps are Out of Range
Section 10.1.3:
Section 10.1.4:
Section 10.2: Bugs
Appendix A: Intel x86 Instruction Reference
Section A.1: Key to Operand Specifications
Section A.2: Key to Opcode Descriptions
Section A.2.1: Register Values
Section A.2.2: Condition Codes
Section A.2.3: Effective Address Encoding: ModR/M and SIB
Section A.3: Key to Instruction Flags
Section A.4:
Section A.5:
Section A.6:
Section A.7:
Section A.8:
Section A.9:
Section A.10:
Section A.11:
Section A.12:
Section A.13:
Section A.14:
Section A.15:
Section A.16:
Section A.17:
Section A.18:
Section A.19:
Section A.20:
Section A.21:
Section A.22:
Section A.23:
Section A.24:
Section A.25:
Section A.26:
Section A.27:
Section A.28:
Section A.29:
Section A.30:
Section A.31:
Section A.32:
Section A.33:
Section A.34:
Section A.35:
Section A.36:
Section A.37:
Section A.38:
Section A.39:
Section A.40:
Section A.41:
Section A.42:
Section A.43:
Section A.44:
Section A.45:
Section A.46:
Section A.47:
Section A.48:
Section A.49:
Section A.50:
Section A.51:
Section A.52:
Section A.53:
Section A.54:
Section A.55:
Section A.56:
Section A.57:
Section A.58:
Section A.59:
Section A.60:
Section A.61:
Section A.62:
Section A.63:
Section A.64:
Section A.65:
Section A.66:
Section A.67:
Section A.68:
Section A.69:
Section A.70:
Section A.71:
Section A.72:
Section A.73:
Section A.74:
Section A.75:
Section A.76:
Section A.77:
Section A.78:
Section A.79:
Section A.80:
Section A.81:
Section A.82:
Section A.83:
Section A.84:
Section A.85:
Section A.86:
Section A.87:
Section A.88:
Section A.89:
Section A.90:
Section A.91:
Section A.92:
Section A.93:
Section A.94:
Section A.95:
Section A.96:
Section A.97:
Section A.98:
Section A.99:
Section A.100:
Section A.101:
Section A.102:
Section A.103:
Section A.104:
Section A.105:
Section A.106:
Section A.107:
Section A.108:
Section A.109:
Section A.110:
Section A.111:
Section A.112:
Section A.113:
Section A.114:
Section A.115:
Section A.116:
Section A.117:
Section A.118:
Section A.119:
Section A.120:
Section A.121:
Section A.122:
Section A.123:
Section A.124:
Section A.125:
Section A.126:
Section A.127:
Section A.128:
Section A.129:
Section A.130:
Section A.131:
Section A.132:
Section A.133:
Section A.134:
Section A.135:
Section A.136:
Section A.137:
Section A.138:
Section A.139:
Section A.140:
Section A.141:
Section A.142:
Section A.143:
Section A.144:
Section A.145:
Section A.146:
Section A.147:
Section A.148:
Section A.149:
Section A.150:
Section A.151:
Section A.152:
Section A.153:
Section A.154:
Section A.155:
Section A.156:
Section A.157:
Section A.158:
Section A.159:
Section A.160:
Section A.161:
Section A.162:
Section A.163:
Section A.164:
Section A.165:
Section A.166:
Section A.167:
Section A.168:
Section A.169:
Section A.170:
Index
-----
Cheers,
June
What's Engineering?
MIT OpenCourseWare |
Electrical Engineering and Computer Science |
6.002 Circuits and Electronics, Spring 2007 |
Lecture Notes and Videos |
detail
Source:
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-002Spring-2007/VideoLectures/detail/embed01.htm
Transcript - Lecture 1
So, one question to ask ourselves is, what is engineering? How do we define, what is engineering? Well, the definition I like to use is one put forth by Steve Senturia, one of our professors who is now retired.
He defined engineering to be the purposeful use of science. All right, so what is 6.002 about? So, 6.002 is a first course in engineering. And I like to view 6.002 as the gainful employment of Maxwell's equations.
Many of you have seen Maxwell's equations before. Most of you should have. And they are hard stuff. 6.002 is all about teaching you how to simplify our lives, make things simple. So, if you can gainfully employ Maxwell's equations, gainfully employ the facts of nature to build very interesting systems.
So let me show you how the transition is made. So, there's a world around us, nature, so we made some observations in nature. We make measurements, and we can write down large tables of measurements.
So, for example, we can take objects and measure the voltage across them, and look at the resulting current through the elements. So, we may end up getting a bunch of values such as [CHALKBOARD]. So, we start out life with making measurements on what exists.
And we build a bunch of tables. Now, we could directly take these tables, and based on observations of these tables, we could go ahead and build very interesting engineering systems that help us out in day-to-day lives.
But that's incredibly hard. Imagine having to resort to a set of tables to do any kind of useful work. So what we do as engineers, we first layer a level of abstraction. We look at all the data, and somehow layer abstraction such that we can simplify or much more succinctly put in a simple equation or a simple statement what these numbers are telling us.
OK, so for example, our physics laws, so laws of physics for example are simply abstractions, the laws of abstractions. So, these sets of numbers can be codified by Ohm's law, for example, V is equal to RI, the voltage current, relates to the resistance of the object.
So, V is equal to RI is a law that succinctly describes a set of experiments, and replaces a large number of tables with a very simple statement. You could call this the law, or you could call it an abstraction.
OK so you see laws of physics, call them abstractions of physics if you like. Similarly, there are Maxwell's equations and so on and so forth. So, this is what is. This is what's out there. OK, and a law as an abstraction describe the properties of nature, as we see it, in some succinct form.
Now, if you want to go and build useful things, we could take these abstractions, take Maxwell's equations, and go and build things. But it's hard. It's really, really hard. And what you learn in, at MIT is this place is all about simplifying things.
Take complicated things, build layers of abstraction, and simplify things so that we can build useful systems. Even in 6.002 we start life by making a huge leap from Maxwell's equations to a couple of very, very simple laws.
OK, I'm going to show you that leap that we will make today. So, the first abstraction that we layer is called the lump circuit abstraction. OK, in the lump circuit abstraction, what we do is we make a set of simplifications that allows us to view a set of objects as discrete or lumped elements.
So, we may, I will define voltage sources. We'll define resistors. We'll define capacitors, and so on. OK, and I'm going to make the jump, and show you how we make the jump in a few minutes. So, on that sort of abstraction, we then layer yet another abstract layer.
And let me call that the amplifier abstraction. OK, remember, here we are absolutely down and dirty. We are setting the probes, measuring objects, and building huge tables. We abstracted things into simple laws, and life got a little better.
OK, I'm going to show you can abstract things further out and build discrete objects, and, you could build even more interesting components called amplifiers and begin playing around with amplifiers.
OK, so when you are using amplifiers, you don't really have to worry about the details of Maxwell's equations. OK, I'll give you some very simple abstract rules of behavior for an amplifier, and you can go build very interesting systems without really, really knowing how Maxwell's equations applies to that because you will be working at this abstract layer.
However, since you're engineers, and you are good at building such systems, it's very important for you to understand how we make this leap from the laws of physics into some of our very primitive engineering abstractions.
So, once we make the amplified abstraction in 6.002, by the way, 6.002 starts here. We start from the laws of physics and then proceed all the way out. So, once we talk about amplifiers we will take two pads.
On the amplifier, you will build the next abstraction called the digital abstraction. OK, and with the digital abstraction, we will build new elements such as inverters and combinational gates, OK? So, notice we are building bigger, and bigger things, which have more and more complicated behavior inside them, but which are very simple to describe, right? So, following the digital abstraction, we will superimpose the combinational logic abstraction on top of that, and define functional blocks that look like this: some inputs, some function, some outputs.
The next abstraction on top of that will be the clock digital abstraction, where we will have some notion of time introduced into the system. There will be a clock, and this will be some function. And there will be a clock that introduces time into the sort of logic values that functions operate upon.
Following that, the next level of abstraction that we build is called instruction set abstraction. OK, now you begin to see things that consumers get to look at. Can someone give me an example of, or name an instruction set, or instruction set abstraction? Bingo.
So, x86 is one set of abstractions. And in fact, in many universities, education could well start just by saying, OK, here's an abstraction. These are the x86 instructions, OK? Some MIT gurus have designed this awesome little microprocessor, OK? So you just worry about, you take this abstraction layer here, the assembly instructions, and you go and build systems on top of that.
OK, so this is an abstraction layer called the x86 layer. There are other abstraction layers. In 6.004, you will learn about, I believe, the alpha or the beta, OK, and various other abstractions at this point.
So, 6.002 kind of goes until here. 6.002 takes me from the world of physics all the way to the world of interesting analog and digital systems. OK, 004, the course on computation structures, will show you how to build computers all the way from simple digital objects all the way to big systems.
Following that, you learn about language abstractions, Java, C, and other languages, and that's in 6.002. And there are several other courses that will cover that. Following this, you learn about software system abstractions, and software systems, you will learn about operating systems.
Any example of an operating system abstraction that people know out there? What's that? Linux. What else? I'm just wondering how long I'll have to go before I hear what I want to hear. [LAUGHTER] OK, so we have a bunch of software systems.
So, if we have a bunch of software systems, these are nothing but abstractions. Linux simply implies a set of system calls that the programs must adhere to. Windows is another set of system calls.
That's it. And see how much money they made out of it? OK, it's all about abstraction layers, that all start from nature. All right? Build abstraction upon abstraction upon abstraction upon abstraction, and someone out here are lots of dollars.
OK, so based on these abstractions, we can then build useful things for human beings. We can build very useful things, video games, so we can send space shuttles up, and a whole bunch of other systems.
But it's based on these abstraction layers. What's unique about education at MIT? What's unique about 6.002 and EECS? Is to my knowledge, there are not many other places in the world where you will get an education in everything going all the way from nature to how to build very complicated analog and digital systems.
OK, we will show you layer upon layer upon layer upon layer, peel away the onion until you are down to raw nature, OK, through Maxwell's equations. So, 6.002, 004, this is 033, OK, 6.170, and so on.
OK, the whole EECS is about building abstraction layers, one on top of the other. So that's one path. There's the analog path. The analog path would take an amplifier, and build an abstraction layer called the op-amp.
See how similar they all look? You know the amplifier, the inverter of the digital world, and the operational amplifier in the analog world, just different ways of looking at the same devices. So, to build an analog system, to build an operational amplifier, and then, here we go end up building a whole bunch of different interesting analog system components.
OK, and these components might look like oscillators. They might look like filters. OK, they look like power supplies, a whole bunch of very interesting abstract components, which pulled together can then give you the next set of systems.
And these systems might be toasters, or say for example other analog systems like the various control systems for various power plants and so on and so forth, and ultimately, fun and dollars. OK, so 6.002 is about going from physics all the way to this point.
We will build interesting analog systems, and take you up to interesting digital system components, from which 004 will take you all the way to building computer architectures. So that, in a nutshell, kind of gives you a feel for the space of EECS.
OK, this chart here is almost a vignette of what EECS at MIT is all about. And this is the world according to Agarwal, because he's teaching 002. OK, so this is 6.002, and the rest of EECS is somewhere out there.
OK, so I'm going to do now is throughout this course; I want you to think about which part in this vignette we are in. So, right now, I'm going to start here and take you here. OK, and as you get closer and closer, things get simpler, and simpler, and simpler.
Still, the final abstractions are pedal, brake, steering wheel. I mean, that's the abstraction to play a game, right, four or five very simple interfaces, and that's all you need to know. And everybody in the world can play stuff.
So remember, this stuff is complicated. This stuff is very, very simple. OK, and the more we build abstractions and come to this side, things get simpler and simpler. So, a large part of what I'll cover today is make the biggest simplification.
The biggest simplification we will make his go from Maxwell's equation to some very, very simple algebraic rules. OK, I did Maxwell's equations myself. And I tell you, they were very interesting stuff but complicated.
I can't imagine building efficient systems using Maxwell's equations. So, let's take an example, OK? So, let's say I have a battery. Just switch to page three of your course notes. And let's say I connect that to a bulb.
OK, and this is a wire. And, the battery supplies some voltage, V, and I ask you a simple question. What is the current through the bulb? OK, so here is something that I can build using objects. I can pick a round from stores and so on.
And I can collect them up in this way, and ask the question, what is the current, I? Now, if all you've done is learn about Maxwell's equations, you can roll up your sleeves and say, ah-ha! The first step is to write down all of Maxwell's equations, and you can say, del cross E is minus del and go on, and on, and on, OK, and write out all of Maxwell's equations and say, now how do I get from there to here? OK, it's very good.
You can do it. OK, you can do it, but it's very complicated. OK, so instead, what you're going to do is take the easy way. So, what I want to remind you is that this course is actually very easy.
OK remember, we're going to be building abstraction upon abstraction to make your lives easier. If you think your lives are getting more complicated, then you are not using intuition enough. OK, just remember the big I word.
It's all about making things simple. OK, so let me give you an analogy. So, suppose you have an object. OK, and I apply a force to the object. It's an analogy, OK to get some insight into how to do this.
So, I say here's an object. I apply a force, and I ask you the question. What is the acceleration of the object when I apply a force, F? So, how would you do it? OK, and eighth, or ninth, or tenth grader can do this.
OK, they would ask me, what's the mass of the object? OK, I ask you what is the acceleration? You would turn around and ask me, what is the mass of the object? I tell you, the mass of the object is M.
And then you say, oh sure, A is F divided by M, done. It's as simple as that. OK, I could have gone into all kinds of differential equations and so on to figure that out, but you asked me for the mass.
And you gave me the answer, A is F divided by M. So, you ignored a bunch of things. You ignored the shape of the object. You ignored its color. You ignored its temperature. OK, and you ignored the soft or hard or whatever.
OK, you ignored a whole bunch of things. You were focused on one thing. OK, you're focused on its mass. And, it turns out that the process really was developed from a set of simplifications. That is called, does anybody remember this? Point mass simplification.
OK, so, in physics, you've done this before. OK, you've simplified your lives by viewing objects as having a mass at a point, and force is acting at that point. OK, M is that property of the object that is of interest to you.
This process is called, in physics, point mass discretization. OK, now using an analogy, and I'm going to show you a similar simple process to do the problem with the light bulb. OK, so take my light bulb again, And I focus on the filament of the light bulb.
OK, all I care about is the current flowing through the light bulb. OK, I don't care about whether the filament is twisted, whether it's hot. I don't care about its shape. I don't care about its color.
All I care about is the current. OK, so to do that, what we can do here at a very high level is since we just need the current and don't care about a bunch of other properties, we will simply replace the bulb with a discrete object called a resistor.
So the discrete object is a resistor, much like the point mass simplification that we did earlier that replaced the bulb filament with a object called a resistor, a discrete object called a resistor.
Or a lump object called resister, and put a value next to it just like the mass for the object, a resistance value, R. OK, now what I can do is in the same manner, replace the battery with an object called a battery object, and connect that here, the voltage, V, applied to it.
V falls across the resistor, and I get my I simply from Ohm's law as we divide by R. So, notice here, to replace this complicated bulb, this really twisty, weird old thing with this discreet thing called a resistor, and its only property of interest was its resistance value, R, direct analogy to what we did there.
So, since R represents the only property of interest, we can simply ignore all the other things. So, notice here, we've done things the simple way. And remember, in EE, in the electrical engineering, we do things the simple way.
OK, we could go the hard route and do Maxwell's equations, and get PhD's in physics, and so on. But out here, we are looking to do useful, interesting systems in the simplest way that we can. OK, we do things a simple way.
All right, so we just did this, and boom, I found out what the current was. Now, I cheated a little bit. I've cheated a little bit. R is a lumped abstraction for the bulb. So, you look at this resistor here.
That is simply a placeholder. It's a stand-in for this complicated thing called a bulb. It's a discreet object. It's a lumped object, and represents the bulb. Now, so most of 6.002 will take off from here, OK, and that's it.
To very simple stuff, like V is equal to IR, it's a simple high school algebra to take off in that direction. But before we go there, it's important to understand, why was it that we were able to make the simplification? OK, we did something else.
Something's going on under the covers here. On the one hand, I say let's use Maxwell's, and then I jump out and say, hey, we can just use this simple thing. I did something that allowed me to go from here to here.
And you need to understand why I did that and how I did that. Understand it once, and then you won't have to need that information again. You just need to understand it. So, let's take a closer look at the bulb filament, and look at what we really did.
So, here's my filament, A, and let's say that the surface area here, I label that SA, and the one down here SB, my voltage, V, applied there, and this is what I call my black box that I've replaced with a resistor.
Notice that, in order for this to work, V and I need to be defined. So I needs to be defined, and V needs to be defined. OK, if I give you a random object, and I don't tell you anything else about the object, it's not clear I can do that.
OK, if it's a much more general situation, I have to write down Maxwell's equations, and this is what I would write down. Write down J dot dS as a function of the coordinate here integrated over the area minus, OK, I would have to start from there from one of Maxwell's equations.
All right, notice that this becomes IA, and this becomes IB in our simplification. But, if I don't tell you anything else, you have to start from here. You will have some varying current here by point.
You might have some other current coming out here because I may have some charge buildup happening inside. If charge is building up inside the filament; then I would have to put del q by del t out here, right, the current in minus the current out must equal charge buildup.
Whoa, where is this and where is that? So this is reality. This is really, really what I have to do. But how did I get there? How did I get there? The key answer is, as engineers, when in doubt we simplify.
Remember, we are engineers. Our goal in life is to build interesting systems. OK and some are motivated by money. OK, so our goal is to build interesting systems and do good to humanity. So, as long as we can build a good light bulb, we are happy.
So what we can do is we can say, look, all I care about is building interesting systems. So I can say, hey, this stuff is too hard. Let's make the assumption that all the systems that we will consider will have this thing be zero.
OK, in other words, if I take a complete object, if I take an element like a resistor or a capacitor, the box around the entire element, OK, and I want to just deal with those systems in which this thing is zero.
You can come and beat me up and say, but why? Why not? Why am I doing this? And I am saying the world is arbitrary. I'm an engineer; I want to build good systems. By making this simplification, I eliminate this squiggle thing, and so on.
I don't want to deal with it. I want to make my life simple. So this is gone to zero because, why? Because I have said that in the future I will only deal with those elements for which this is true.
I'm going to discipline myself. I'm going to discipline myself to only deal with those systems. OK, Maxwell is turning around and, you know, mad at me and all that stuff, but tough. So this, what I've said about making a simplification here, and this is one of the simplifications I'm making.
And I give a name to the simplification. And that's called the lumped matter discipline. OK, so I'm saying I will only deal with elements for which if I put a black box around it, this is going to be true.
And if this is going to be true, then notice, there is no charge buildup. Current in must equal current out. Ah-ha! So this becomes IA. This becomes IB. Yes. OK, I can now deal with IA's and IB's.
And IB and IA are equal because this is zero. Notice that there is a whole bunch of depth here in the jump from here to here. As MIT graduates, you really, really need to understand why it is that we made that jump, and then go and use that, and do cool things.
All right, this allows us to define I. We have a unique I associated with an element for the current through the element. We still have to worry about B, and I won't go through that in detail. The course notes have some discussion of that and so does the textbook.
So V, AB is defined when del phi B, the rate of change of magnetic flux is zero. So, if I take the element and I take any region outside the element, this must be true. And you say, why should that be true? That's not true in general.
Absolutely. It's not true in general. But I, because I choose to, I going to deal with only those elements. I will discipline myself. But these are only those elements for which this is true, and this is true.
I'm going to limit my world. I'm going to create a play field for myself. You want to play; follow my rules. OK, and that's called the lumped matter discipline. So once you say that I'm going to adhere to the lump matter discipline, and this is true inside your elements.
This is true outside the elements. You can define VA and VB, and good things happen to you. OK, let me show you a few examples of lumped elements. But remember, a large part of what we're doing is based on these two assumptions.
And to just go through the background on that, I would encourage you to go to chapter 1 of your course notes and read through just as how this came about, that comes about. So, by doing that by adhering to a lumped matter discipline, we can now lump objects.
We could lump a bulb into a resistor. OK, so to be clear, a certain number of lumped objects, and now, the universe is going to be comprised into lumped objects. OK, so before this, when he went home, we talked about eggs, and omelets, and light bulbs, and switches, but once you come to MIT, and after you've taken 6.002, you begin talking about lumped elements, you know, resistors, voltage sources, capacitors, little inky-dinky objects that follow the lumped matter discipline.
OK, they stick to very simple rules, and the math that you have to do to analyze them is incredibly simple. What could be simpler than V is equal to IR? So, let me give you an example of interesting lumped elements, and then show you a couple of really nasty lumped elements.
OK. OK, so what you see out here, so we characterize lumped elements by the VI characteristics. OK, you apply voltage, measure the current. OK, so what I can do is I can plot I here, and V here, and see what it looks like.
OK, I can characterize elements by their VI relationship. And there are a bunch of elements that I can create based on the VI relationship. So let me show you a few examples. So for the resistor, since V is directly proportional to I, and R is a constant, I get a straight line.
That's the I axis, the V axis, and this is the resistor. What I actually have is a variable resistor, so I'm going to change the resistance value, R, and the curve will also change slope. OK, I changed the value of R because it's a variable resistor, and the changes slope because my R is different.
OK, next, let me go to a fixed resistor, and this guy here on the screen to your left is a fixed resistor. And you see that its IV characteristic is a line of a given slope, 1 by R, and that's it. I can't change it.
Number three, I have another lumped element called a Zener diode that you will see in the fourth week of this class, and the characteristics for the Zener diode look like this: IV. If my voltage goes across the Zener diode goes up slightly, the current shoots up.
But if the voltage becomes negative I don't have any current flowing into it until the voltage passes on the threshold, at which point my current begins to build up. OK, so I can increase the voltage a little bit, and it can show that the current starts building up again.
So that's another interesting lumped element called a Zener diode. Let's switch to the next one called a diode. So a diode looks like this: IV. As the voltage across the diode becomes positive, around .6 volts, or thereabout, the current begins to shoot up.
But when the voltage is below that threshold of .6, then my current is almost zero. It's another lumped element called a diode. And you will begin using these elements in your 002 lives to build interesting systems.
The next example is a thermistor. A thermistor is a resistor whose resistance varies with temperature. OK, so this is a very expensive little hairdryer, and what I'm going to do is blow some hot air at my resistor, and you're going to see that its value is going to change depending on how much I heat it.
So as it cools down, let me cool it down, so you can see it's coming down. I can zap it again. I could do this all day. This is so much fun. OK, so that's another interesting lumped element. As the temperature rises, its resistance changes.
The next thing is called a photo resistor. It's a resistor. It used to be a resistor; Lorenzo? Oh OK, that's fine. So this is a photo resistor. And notice that it almost behaves like an open circuit.
But what I'm going to do is shine some light on it. When I shine light on it, it begins to conduct and becomes a resistor of some value. There you go. OK, so that's a photo resistor. So now I'm going to show you a battery.
Notice we did talk about batteries before. I'll show you a battery. So before you show a battery, just thinking your own minds, what should the IV characteristic of a battery look like? IV. A battery supplies a constant voltage.
You know your little cell, the AA battery, 1.5 volts? So, think of what the IV characteristic of a battery should look like for three seconds before it shows you. This is the one I showed, Lorenzo?.
It's a straight line. This is a good battery. It's a straight, vertical line, but says that the voltage is 1.5 volts, or thereabouts. No matter what current it supplies as an ideal voltage source, it has a fixed voltage, V, and no matter what the current going through is.
Now, I'll show you a dud, a bad battery, and this is what the bad battery looks like. So, many of you have had your car batteries die on you. When you go to the store, they check your batteries. They use exactly this principle, that dead batteries have resistance.
By the way, you see slopes here. You're thinking of resistance. OK, they can use this property to figure out that your battery is dead. So that's a dead battery. And finally, let me show you a bulb.
We started with a bulb, and so I need to end, OK, we started with a bulb, so I need to end with a bulb. And what you will see is that a bulb simply behaves like a resistor. Its IV curve is going to look like this.
OK, notice this is my bulb. And guess what, it behaves like a resistor. It's a very interesting kind of resistor, so I won't go into details for now. But notice its IV characteristic behaves like a resistor.
OK, so those are some pretty standard lumped elements. You deal with a lot more sets of lumped elements, switches, MOSFETs, capacitors, inductors, a bunch of other fun stuff. But before we do that, what I wanted to tell you, don't go berserk on this abstraction binge.
Too much of anything is bad for you. So what I'm going to show you is, abstractions or models are only valid provided you work within a set of constraints. Notice, we have already had this tacit handshake which said that we follow the discipline.
Even after we follow the discipline, there are ranges to how well physical elements can behave like ideal lumped elements. OK, for example, what we will do is show you the resistor. And it's going to look like a resistor.
And I'm going to keep increasing the voltage around it. OK, what's going to happen at some point? I just keep doing that. If it's an ideal element, if you're a theorist, you say, oh yeah, the curve will keep extending until I reach infinity.
But this is a practical resistor, so people out here can cover your eyes or something. OK, so you're abstraction can't predict that. All it says is the current is an amp. It can't predict the heat, light, or the smell.
In the laboratory, even, you get the smell. You know what somebody has just done. So that's one example of the lumped abstraction breaking down. So, if I really believe that my own BS, anything is a lumped element.
So here's a pickle. A pickle is a lumped element. I can choose it as a lumped resistor. But this is a very interesting lumped resistor. Don't try this at home. This is a standard pickle into which you are pumping 110 V AC.
I promise you, this is a standard pickle. So, it has a fixed resistance, but your lumped abstraction cannot predict the nice light and sound effect. OK, so the last two or three minutes what I want to do, so remember, don't get carried away by abstractions.
There are limits. OK, you can't predict everything. OK, that's the smell of a pickle. OK, so let me give you a preview of some upcoming attractions, and show you one more quick simplification in the last few minutes.
So what we can do, once we build these lumped elements, we can connect them in circuits. OK, so I can build a circuit, of the sort. So here's a voltage source with a bunch of resistors. I can connect them with wires and build a circuit of the sort.
One interesting question we can ask ourselves is, under the lumped matter discipline, what can we say about the voltages? OK, if I go around the loop, provided my world adheres to the lumped matter discipline, what can I say about the voltages around this loop? Ah-ha, Maxwell again, right? So, I can write Maxwell's appropriate equation to solve that.
OK, voltages have something to do with E and your integral of E dot dl and all of that stuff, right? So this is the appropriate Maxwell's equations to use. And I want to find out what happens here.
Now remember, under LMD, I made the assumption. OK, my world, my playground, has del phi B by del t being zero. The rate of change of flux is zero. So, under these circumstances, I can write this.
I can break up this line integral into three parts across the voltage source and across the two resistors and write that down. OK, and then when I can do, is now that the right-hand side is zero, I can simply take this.
And I know that E dot dl across this element is simply VCA. This is VAB, and this is VBC equals zero. OK, so when I make the assumption that del phi B by del t is zero, and I go around this loop, apply Maxwell's equations, what do I find? I find that the sum of the voltages, VCA plus VAB plus VBC, is zero.
That's fantastic. So now, I could say hasta la vista to this baby here. And I can focus on this guy and say, Maxwell's equations, this thing with squiggles and dels and all that stuff, can be simplified to the sum of the voltages across a set of elements in a loop in a circuit is zero.
OK, and this is called Kirchhoff's first first law, KVL. OK, similarly, in recitation section, you'll see the application of Kirchhoff's current law, which comes from this be equal to zero, and all the currents coming into a node being zero.
So, KVL and KCl directly come out of the lumped matter discipline. And you can use those to solve circuits like this.
-----
Cheers,
June
Electrical Engineering and Computer Science |
6.002 Circuits and Electronics, Spring 2007 |
Lecture Notes and Videos |
detail
Source:
http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-002Spring-2007/VideoLectures/detail/embed01.htm
Transcript - Lecture 1
So, one question to ask ourselves is, what is engineering? How do we define, what is engineering? Well, the definition I like to use is one put forth by Steve Senturia, one of our professors who is now retired.
He defined engineering to be the purposeful use of science. All right, so what is 6.002 about? So, 6.002 is a first course in engineering. And I like to view 6.002 as the gainful employment of Maxwell's equations.
Many of you have seen Maxwell's equations before. Most of you should have. And they are hard stuff. 6.002 is all about teaching you how to simplify our lives, make things simple. So, if you can gainfully employ Maxwell's equations, gainfully employ the facts of nature to build very interesting systems.
So let me show you how the transition is made. So, there's a world around us, nature, so we made some observations in nature. We make measurements, and we can write down large tables of measurements.
So, for example, we can take objects and measure the voltage across them, and look at the resulting current through the elements. So, we may end up getting a bunch of values such as [CHALKBOARD]. So, we start out life with making measurements on what exists.
And we build a bunch of tables. Now, we could directly take these tables, and based on observations of these tables, we could go ahead and build very interesting engineering systems that help us out in day-to-day lives.
But that's incredibly hard. Imagine having to resort to a set of tables to do any kind of useful work. So what we do as engineers, we first layer a level of abstraction. We look at all the data, and somehow layer abstraction such that we can simplify or much more succinctly put in a simple equation or a simple statement what these numbers are telling us.
OK, so for example, our physics laws, so laws of physics for example are simply abstractions, the laws of abstractions. So, these sets of numbers can be codified by Ohm's law, for example, V is equal to RI, the voltage current, relates to the resistance of the object.
So, V is equal to RI is a law that succinctly describes a set of experiments, and replaces a large number of tables with a very simple statement. You could call this the law, or you could call it an abstraction.
OK so you see laws of physics, call them abstractions of physics if you like. Similarly, there are Maxwell's equations and so on and so forth. So, this is what is. This is what's out there. OK, and a law as an abstraction describe the properties of nature, as we see it, in some succinct form.
Now, if you want to go and build useful things, we could take these abstractions, take Maxwell's equations, and go and build things. But it's hard. It's really, really hard. And what you learn in, at MIT is this place is all about simplifying things.
Take complicated things, build layers of abstraction, and simplify things so that we can build useful systems. Even in 6.002 we start life by making a huge leap from Maxwell's equations to a couple of very, very simple laws.
OK, I'm going to show you that leap that we will make today. So, the first abstraction that we layer is called the lump circuit abstraction. OK, in the lump circuit abstraction, what we do is we make a set of simplifications that allows us to view a set of objects as discrete or lumped elements.
So, we may, I will define voltage sources. We'll define resistors. We'll define capacitors, and so on. OK, and I'm going to make the jump, and show you how we make the jump in a few minutes. So, on that sort of abstraction, we then layer yet another abstract layer.
And let me call that the amplifier abstraction. OK, remember, here we are absolutely down and dirty. We are setting the probes, measuring objects, and building huge tables. We abstracted things into simple laws, and life got a little better.
OK, I'm going to show you can abstract things further out and build discrete objects, and, you could build even more interesting components called amplifiers and begin playing around with amplifiers.
OK, so when you are using amplifiers, you don't really have to worry about the details of Maxwell's equations. OK, I'll give you some very simple abstract rules of behavior for an amplifier, and you can go build very interesting systems without really, really knowing how Maxwell's equations applies to that because you will be working at this abstract layer.
However, since you're engineers, and you are good at building such systems, it's very important for you to understand how we make this leap from the laws of physics into some of our very primitive engineering abstractions.
So, once we make the amplified abstraction in 6.002, by the way, 6.002 starts here. We start from the laws of physics and then proceed all the way out. So, once we talk about amplifiers we will take two pads.
On the amplifier, you will build the next abstraction called the digital abstraction. OK, and with the digital abstraction, we will build new elements such as inverters and combinational gates, OK? So, notice we are building bigger, and bigger things, which have more and more complicated behavior inside them, but which are very simple to describe, right? So, following the digital abstraction, we will superimpose the combinational logic abstraction on top of that, and define functional blocks that look like this: some inputs, some function, some outputs.
The next abstraction on top of that will be the clock digital abstraction, where we will have some notion of time introduced into the system. There will be a clock, and this will be some function. And there will be a clock that introduces time into the sort of logic values that functions operate upon.
Following that, the next level of abstraction that we build is called instruction set abstraction. OK, now you begin to see things that consumers get to look at. Can someone give me an example of, or name an instruction set, or instruction set abstraction? Bingo.
So, x86 is one set of abstractions. And in fact, in many universities, education could well start just by saying, OK, here's an abstraction. These are the x86 instructions, OK? Some MIT gurus have designed this awesome little microprocessor, OK? So you just worry about, you take this abstraction layer here, the assembly instructions, and you go and build systems on top of that.
OK, so this is an abstraction layer called the x86 layer. There are other abstraction layers. In 6.004, you will learn about, I believe, the alpha or the beta, OK, and various other abstractions at this point.
So, 6.002 kind of goes until here. 6.002 takes me from the world of physics all the way to the world of interesting analog and digital systems. OK, 004, the course on computation structures, will show you how to build computers all the way from simple digital objects all the way to big systems.
Following that, you learn about language abstractions, Java, C, and other languages, and that's in 6.002. And there are several other courses that will cover that. Following this, you learn about software system abstractions, and software systems, you will learn about operating systems.
Any example of an operating system abstraction that people know out there? What's that? Linux. What else? I'm just wondering how long I'll have to go before I hear what I want to hear. [LAUGHTER] OK, so we have a bunch of software systems.
So, if we have a bunch of software systems, these are nothing but abstractions. Linux simply implies a set of system calls that the programs must adhere to. Windows is another set of system calls.
That's it. And see how much money they made out of it? OK, it's all about abstraction layers, that all start from nature. All right? Build abstraction upon abstraction upon abstraction upon abstraction, and someone out here are lots of dollars.
OK, so based on these abstractions, we can then build useful things for human beings. We can build very useful things, video games, so we can send space shuttles up, and a whole bunch of other systems.
But it's based on these abstraction layers. What's unique about education at MIT? What's unique about 6.002 and EECS? Is to my knowledge, there are not many other places in the world where you will get an education in everything going all the way from nature to how to build very complicated analog and digital systems.
OK, we will show you layer upon layer upon layer upon layer, peel away the onion until you are down to raw nature, OK, through Maxwell's equations. So, 6.002, 004, this is 033, OK, 6.170, and so on.
OK, the whole EECS is about building abstraction layers, one on top of the other. So that's one path. There's the analog path. The analog path would take an amplifier, and build an abstraction layer called the op-amp.
See how similar they all look? You know the amplifier, the inverter of the digital world, and the operational amplifier in the analog world, just different ways of looking at the same devices. So, to build an analog system, to build an operational amplifier, and then, here we go end up building a whole bunch of different interesting analog system components.
OK, and these components might look like oscillators. They might look like filters. OK, they look like power supplies, a whole bunch of very interesting abstract components, which pulled together can then give you the next set of systems.
And these systems might be toasters, or say for example other analog systems like the various control systems for various power plants and so on and so forth, and ultimately, fun and dollars. OK, so 6.002 is about going from physics all the way to this point.
We will build interesting analog systems, and take you up to interesting digital system components, from which 004 will take you all the way to building computer architectures. So that, in a nutshell, kind of gives you a feel for the space of EECS.
OK, this chart here is almost a vignette of what EECS at MIT is all about. And this is the world according to Agarwal, because he's teaching 002. OK, so this is 6.002, and the rest of EECS is somewhere out there.
OK, so I'm going to do now is throughout this course; I want you to think about which part in this vignette we are in. So, right now, I'm going to start here and take you here. OK, and as you get closer and closer, things get simpler, and simpler, and simpler.
Still, the final abstractions are pedal, brake, steering wheel. I mean, that's the abstraction to play a game, right, four or five very simple interfaces, and that's all you need to know. And everybody in the world can play stuff.
So remember, this stuff is complicated. This stuff is very, very simple. OK, and the more we build abstractions and come to this side, things get simpler and simpler. So, a large part of what I'll cover today is make the biggest simplification.
The biggest simplification we will make his go from Maxwell's equation to some very, very simple algebraic rules. OK, I did Maxwell's equations myself. And I tell you, they were very interesting stuff but complicated.
I can't imagine building efficient systems using Maxwell's equations. So, let's take an example, OK? So, let's say I have a battery. Just switch to page three of your course notes. And let's say I connect that to a bulb.
OK, and this is a wire. And, the battery supplies some voltage, V, and I ask you a simple question. What is the current through the bulb? OK, so here is something that I can build using objects. I can pick a round from stores and so on.
And I can collect them up in this way, and ask the question, what is the current, I? Now, if all you've done is learn about Maxwell's equations, you can roll up your sleeves and say, ah-ha! The first step is to write down all of Maxwell's equations, and you can say, del cross E is minus del and go on, and on, and on, OK, and write out all of Maxwell's equations and say, now how do I get from there to here? OK, it's very good.
You can do it. OK, you can do it, but it's very complicated. OK, so instead, what you're going to do is take the easy way. So, what I want to remind you is that this course is actually very easy.
OK remember, we're going to be building abstraction upon abstraction to make your lives easier. If you think your lives are getting more complicated, then you are not using intuition enough. OK, just remember the big I word.
It's all about making things simple. OK, so let me give you an analogy. So, suppose you have an object. OK, and I apply a force to the object. It's an analogy, OK to get some insight into how to do this.
So, I say here's an object. I apply a force, and I ask you the question. What is the acceleration of the object when I apply a force, F? So, how would you do it? OK, and eighth, or ninth, or tenth grader can do this.
OK, they would ask me, what's the mass of the object? OK, I ask you what is the acceleration? You would turn around and ask me, what is the mass of the object? I tell you, the mass of the object is M.
And then you say, oh sure, A is F divided by M, done. It's as simple as that. OK, I could have gone into all kinds of differential equations and so on to figure that out, but you asked me for the mass.
And you gave me the answer, A is F divided by M. So, you ignored a bunch of things. You ignored the shape of the object. You ignored its color. You ignored its temperature. OK, and you ignored the soft or hard or whatever.
OK, you ignored a whole bunch of things. You were focused on one thing. OK, you're focused on its mass. And, it turns out that the process really was developed from a set of simplifications. That is called, does anybody remember this? Point mass simplification.
OK, so, in physics, you've done this before. OK, you've simplified your lives by viewing objects as having a mass at a point, and force is acting at that point. OK, M is that property of the object that is of interest to you.
This process is called, in physics, point mass discretization. OK, now using an analogy, and I'm going to show you a similar simple process to do the problem with the light bulb. OK, so take my light bulb again, And I focus on the filament of the light bulb.
OK, all I care about is the current flowing through the light bulb. OK, I don't care about whether the filament is twisted, whether it's hot. I don't care about its shape. I don't care about its color.
All I care about is the current. OK, so to do that, what we can do here at a very high level is since we just need the current and don't care about a bunch of other properties, we will simply replace the bulb with a discrete object called a resistor.
So the discrete object is a resistor, much like the point mass simplification that we did earlier that replaced the bulb filament with a object called a resistor, a discrete object called a resistor.
Or a lump object called resister, and put a value next to it just like the mass for the object, a resistance value, R. OK, now what I can do is in the same manner, replace the battery with an object called a battery object, and connect that here, the voltage, V, applied to it.
V falls across the resistor, and I get my I simply from Ohm's law as we divide by R. So, notice here, to replace this complicated bulb, this really twisty, weird old thing with this discreet thing called a resistor, and its only property of interest was its resistance value, R, direct analogy to what we did there.
So, since R represents the only property of interest, we can simply ignore all the other things. So, notice here, we've done things the simple way. And remember, in EE, in the electrical engineering, we do things the simple way.
OK, we could go the hard route and do Maxwell's equations, and get PhD's in physics, and so on. But out here, we are looking to do useful, interesting systems in the simplest way that we can. OK, we do things a simple way.
All right, so we just did this, and boom, I found out what the current was. Now, I cheated a little bit. I've cheated a little bit. R is a lumped abstraction for the bulb. So, you look at this resistor here.
That is simply a placeholder. It's a stand-in for this complicated thing called a bulb. It's a discreet object. It's a lumped object, and represents the bulb. Now, so most of 6.002 will take off from here, OK, and that's it.
To very simple stuff, like V is equal to IR, it's a simple high school algebra to take off in that direction. But before we go there, it's important to understand, why was it that we were able to make the simplification? OK, we did something else.
Something's going on under the covers here. On the one hand, I say let's use Maxwell's, and then I jump out and say, hey, we can just use this simple thing. I did something that allowed me to go from here to here.
And you need to understand why I did that and how I did that. Understand it once, and then you won't have to need that information again. You just need to understand it. So, let's take a closer look at the bulb filament, and look at what we really did.
So, here's my filament, A, and let's say that the surface area here, I label that SA, and the one down here SB, my voltage, V, applied there, and this is what I call my black box that I've replaced with a resistor.
Notice that, in order for this to work, V and I need to be defined. So I needs to be defined, and V needs to be defined. OK, if I give you a random object, and I don't tell you anything else about the object, it's not clear I can do that.
OK, if it's a much more general situation, I have to write down Maxwell's equations, and this is what I would write down. Write down J dot dS as a function of the coordinate here integrated over the area minus, OK, I would have to start from there from one of Maxwell's equations.
All right, notice that this becomes IA, and this becomes IB in our simplification. But, if I don't tell you anything else, you have to start from here. You will have some varying current here by point.
You might have some other current coming out here because I may have some charge buildup happening inside. If charge is building up inside the filament; then I would have to put del q by del t out here, right, the current in minus the current out must equal charge buildup.
Whoa, where is this and where is that? So this is reality. This is really, really what I have to do. But how did I get there? How did I get there? The key answer is, as engineers, when in doubt we simplify.
Remember, we are engineers. Our goal in life is to build interesting systems. OK and some are motivated by money. OK, so our goal is to build interesting systems and do good to humanity. So, as long as we can build a good light bulb, we are happy.
So what we can do is we can say, look, all I care about is building interesting systems. So I can say, hey, this stuff is too hard. Let's make the assumption that all the systems that we will consider will have this thing be zero.
OK, in other words, if I take a complete object, if I take an element like a resistor or a capacitor, the box around the entire element, OK, and I want to just deal with those systems in which this thing is zero.
You can come and beat me up and say, but why? Why not? Why am I doing this? And I am saying the world is arbitrary. I'm an engineer; I want to build good systems. By making this simplification, I eliminate this squiggle thing, and so on.
I don't want to deal with it. I want to make my life simple. So this is gone to zero because, why? Because I have said that in the future I will only deal with those elements for which this is true.
I'm going to discipline myself. I'm going to discipline myself to only deal with those systems. OK, Maxwell is turning around and, you know, mad at me and all that stuff, but tough. So this, what I've said about making a simplification here, and this is one of the simplifications I'm making.
And I give a name to the simplification. And that's called the lumped matter discipline. OK, so I'm saying I will only deal with elements for which if I put a black box around it, this is going to be true.
And if this is going to be true, then notice, there is no charge buildup. Current in must equal current out. Ah-ha! So this becomes IA. This becomes IB. Yes. OK, I can now deal with IA's and IB's.
And IB and IA are equal because this is zero. Notice that there is a whole bunch of depth here in the jump from here to here. As MIT graduates, you really, really need to understand why it is that we made that jump, and then go and use that, and do cool things.
All right, this allows us to define I. We have a unique I associated with an element for the current through the element. We still have to worry about B, and I won't go through that in detail. The course notes have some discussion of that and so does the textbook.
So V, AB is defined when del phi B, the rate of change of magnetic flux is zero. So, if I take the element and I take any region outside the element, this must be true. And you say, why should that be true? That's not true in general.
Absolutely. It's not true in general. But I, because I choose to, I going to deal with only those elements. I will discipline myself. But these are only those elements for which this is true, and this is true.
I'm going to limit my world. I'm going to create a play field for myself. You want to play; follow my rules. OK, and that's called the lumped matter discipline. So once you say that I'm going to adhere to the lump matter discipline, and this is true inside your elements.
This is true outside the elements. You can define VA and VB, and good things happen to you. OK, let me show you a few examples of lumped elements. But remember, a large part of what we're doing is based on these two assumptions.
And to just go through the background on that, I would encourage you to go to chapter 1 of your course notes and read through just as how this came about, that comes about. So, by doing that by adhering to a lumped matter discipline, we can now lump objects.
We could lump a bulb into a resistor. OK, so to be clear, a certain number of lumped objects, and now, the universe is going to be comprised into lumped objects. OK, so before this, when he went home, we talked about eggs, and omelets, and light bulbs, and switches, but once you come to MIT, and after you've taken 6.002, you begin talking about lumped elements, you know, resistors, voltage sources, capacitors, little inky-dinky objects that follow the lumped matter discipline.
OK, they stick to very simple rules, and the math that you have to do to analyze them is incredibly simple. What could be simpler than V is equal to IR? So, let me give you an example of interesting lumped elements, and then show you a couple of really nasty lumped elements.
OK. OK, so what you see out here, so we characterize lumped elements by the VI characteristics. OK, you apply voltage, measure the current. OK, so what I can do is I can plot I here, and V here, and see what it looks like.
OK, I can characterize elements by their VI relationship. And there are a bunch of elements that I can create based on the VI relationship. So let me show you a few examples. So for the resistor, since V is directly proportional to I, and R is a constant, I get a straight line.
That's the I axis, the V axis, and this is the resistor. What I actually have is a variable resistor, so I'm going to change the resistance value, R, and the curve will also change slope. OK, I changed the value of R because it's a variable resistor, and the changes slope because my R is different.
OK, next, let me go to a fixed resistor, and this guy here on the screen to your left is a fixed resistor. And you see that its IV characteristic is a line of a given slope, 1 by R, and that's it. I can't change it.
Number three, I have another lumped element called a Zener diode that you will see in the fourth week of this class, and the characteristics for the Zener diode look like this: IV. If my voltage goes across the Zener diode goes up slightly, the current shoots up.
But if the voltage becomes negative I don't have any current flowing into it until the voltage passes on the threshold, at which point my current begins to build up. OK, so I can increase the voltage a little bit, and it can show that the current starts building up again.
So that's another interesting lumped element called a Zener diode. Let's switch to the next one called a diode. So a diode looks like this: IV. As the voltage across the diode becomes positive, around .6 volts, or thereabout, the current begins to shoot up.
But when the voltage is below that threshold of .6, then my current is almost zero. It's another lumped element called a diode. And you will begin using these elements in your 002 lives to build interesting systems.
The next example is a thermistor. A thermistor is a resistor whose resistance varies with temperature. OK, so this is a very expensive little hairdryer, and what I'm going to do is blow some hot air at my resistor, and you're going to see that its value is going to change depending on how much I heat it.
So as it cools down, let me cool it down, so you can see it's coming down. I can zap it again. I could do this all day. This is so much fun. OK, so that's another interesting lumped element. As the temperature rises, its resistance changes.
The next thing is called a photo resistor. It's a resistor. It used to be a resistor; Lorenzo? Oh OK, that's fine. So this is a photo resistor. And notice that it almost behaves like an open circuit.
But what I'm going to do is shine some light on it. When I shine light on it, it begins to conduct and becomes a resistor of some value. There you go. OK, so that's a photo resistor. So now I'm going to show you a battery.
Notice we did talk about batteries before. I'll show you a battery. So before you show a battery, just thinking your own minds, what should the IV characteristic of a battery look like? IV. A battery supplies a constant voltage.
You know your little cell, the AA battery, 1.5 volts? So, think of what the IV characteristic of a battery should look like for three seconds before it shows you. This is the one I showed, Lorenzo?.
It's a straight line. This is a good battery. It's a straight, vertical line, but says that the voltage is 1.5 volts, or thereabouts. No matter what current it supplies as an ideal voltage source, it has a fixed voltage, V, and no matter what the current going through is.
Now, I'll show you a dud, a bad battery, and this is what the bad battery looks like. So, many of you have had your car batteries die on you. When you go to the store, they check your batteries. They use exactly this principle, that dead batteries have resistance.
By the way, you see slopes here. You're thinking of resistance. OK, they can use this property to figure out that your battery is dead. So that's a dead battery. And finally, let me show you a bulb.
We started with a bulb, and so I need to end, OK, we started with a bulb, so I need to end with a bulb. And what you will see is that a bulb simply behaves like a resistor. Its IV curve is going to look like this.
OK, notice this is my bulb. And guess what, it behaves like a resistor. It's a very interesting kind of resistor, so I won't go into details for now. But notice its IV characteristic behaves like a resistor.
OK, so those are some pretty standard lumped elements. You deal with a lot more sets of lumped elements, switches, MOSFETs, capacitors, inductors, a bunch of other fun stuff. But before we do that, what I wanted to tell you, don't go berserk on this abstraction binge.
Too much of anything is bad for you. So what I'm going to show you is, abstractions or models are only valid provided you work within a set of constraints. Notice, we have already had this tacit handshake which said that we follow the discipline.
Even after we follow the discipline, there are ranges to how well physical elements can behave like ideal lumped elements. OK, for example, what we will do is show you the resistor. And it's going to look like a resistor.
And I'm going to keep increasing the voltage around it. OK, what's going to happen at some point? I just keep doing that. If it's an ideal element, if you're a theorist, you say, oh yeah, the curve will keep extending until I reach infinity.
But this is a practical resistor, so people out here can cover your eyes or something. OK, so you're abstraction can't predict that. All it says is the current is an amp. It can't predict the heat, light, or the smell.
In the laboratory, even, you get the smell. You know what somebody has just done. So that's one example of the lumped abstraction breaking down. So, if I really believe that my own BS, anything is a lumped element.
So here's a pickle. A pickle is a lumped element. I can choose it as a lumped resistor. But this is a very interesting lumped resistor. Don't try this at home. This is a standard pickle into which you are pumping 110 V AC.
I promise you, this is a standard pickle. So, it has a fixed resistance, but your lumped abstraction cannot predict the nice light and sound effect. OK, so the last two or three minutes what I want to do, so remember, don't get carried away by abstractions.
There are limits. OK, you can't predict everything. OK, that's the smell of a pickle. OK, so let me give you a preview of some upcoming attractions, and show you one more quick simplification in the last few minutes.
So what we can do, once we build these lumped elements, we can connect them in circuits. OK, so I can build a circuit, of the sort. So here's a voltage source with a bunch of resistors. I can connect them with wires and build a circuit of the sort.
One interesting question we can ask ourselves is, under the lumped matter discipline, what can we say about the voltages? OK, if I go around the loop, provided my world adheres to the lumped matter discipline, what can I say about the voltages around this loop? Ah-ha, Maxwell again, right? So, I can write Maxwell's appropriate equation to solve that.
OK, voltages have something to do with E and your integral of E dot dl and all of that stuff, right? So this is the appropriate Maxwell's equations to use. And I want to find out what happens here.
Now remember, under LMD, I made the assumption. OK, my world, my playground, has del phi B by del t being zero. The rate of change of flux is zero. So, under these circumstances, I can write this.
I can break up this line integral into three parts across the voltage source and across the two resistors and write that down. OK, and then when I can do, is now that the right-hand side is zero, I can simply take this.
And I know that E dot dl across this element is simply VCA. This is VAB, and this is VBC equals zero. OK, so when I make the assumption that del phi B by del t is zero, and I go around this loop, apply Maxwell's equations, what do I find? I find that the sum of the voltages, VCA plus VAB plus VBC, is zero.
That's fantastic. So now, I could say hasta la vista to this baby here. And I can focus on this guy and say, Maxwell's equations, this thing with squiggles and dels and all that stuff, can be simplified to the sum of the voltages across a set of elements in a loop in a circuit is zero.
OK, and this is called Kirchhoff's first first law, KVL. OK, similarly, in recitation section, you'll see the application of Kirchhoff's current law, which comes from this be equal to zero, and all the currents coming into a node being zero.
So, KVL and KCl directly come out of the lumped matter discipline. And you can use those to solve circuits like this.
-----
Cheers,
June
목요일, 9월 17, 2009
DLL Test in C/C++, Delphi
사용하지 않고 있다가 꼭 사용할 때가 되면 잊어 버린다.
잊어 버릴까봐 일단 급하게 적어 둔다... -_-;;; 쳇..!
//
// Project:
// Purpose: DLL test
// Author: HoJung Kim (godmode2k@hotmail.com)
// Date: September 17, 2009
// NOTE:
//
//
// Linux ================================================================
//
// [In C/C++]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
extern "C" int __FUNCTION__(int, float, float, int, float, char*);
extern "C" int __FUNCTION__(int a1, float a2, float a3, int a4, float a5, char* a6) {
...
}
// Build
GCC_BIN=/usr/bin/gcc
INC_LIB_SO_FLAGS="-DLINUX"
INC_SO="-fPIC -shared -Wl,-soname,$LIB_OUTPUT_SO_NAME -o $LIB_WORK_DIR$LIB_OUTPUT_SO *.o"
$GCC_BIN $INC_LIB_SO_FLAGS $INC_SO
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
#ifdef __LINUX__
# include
#else
/* __WIN32__ || _WIN32 || WIN32 */
# include
#endif
#ifdef __LINUX__
//# define dl_load(a) dlopen(a, RTLD_NOWIRTLD_GLOBAL)
# define dl_load(a) dlopen(a, RTLD_NOW)
# define dl_close(a) dlclose(a)
# define dl_sym(a, str) dlsym(a, str)
# define dl_error dlerror
typedef void* g_pFnc;
typedef g_pFnc g_pHandle;
#else
/* __WIN32__ || _WIN32 || WIN32 */
# define dl_load(a) LoadLibrary(a)
# define dl_close(a) FreeLibrary(a)
# define dl_sym(a, str) GetProcAddress(a, str)
#endif
typedef int (*gFp)(int, float, float, int, float, char*)
#endif
//
int main(int argc, char** argv) {
#ifdef __LINUX__
g_pHandle dlFile = VM_null;
//dlFile = dl_load( "test.so" );
dlFile = dl_load( "./test.so" );
#else
/* __WIN32__ || _WIN32 || WIN32 */
g_pHandle dlFile = 0;
dlFile = dl_load( "test.dll" );
#endif
if( !dlFile ) {
#ifdef __LINUX__
fprintf( stderr, "Error: Library load: %s\n", dl_error() );
#else
/* __WIN32__ || _WIN32 || WIN32 */
fprintf( stderr, "Error: Library load: %d\n", GetLastError() );
#endif
return -1;
}
gFp fnXXXXX = (gFp)dl_sym( dlFile, "XXXXX" );
if( !fnXXXXX ) {
#if __LINUX__
fprintf( stderr, "Error: Library link: %p\n", vmCC );
#else
/* __WIN32__ || _WIN32 || WIN32 */
fprintf( stderr, "Error: Library link: %d\n", GetLastError() );
#endif
return -1;
}
fprintf( stdout, "Test\n" );
if( argc < 2 ) {
return -1;
}
fnXXXXX( ..... );
dl_close( dlFile );
return 0;
}
//
// WIN32 ================================================================
//
// [In C/C++]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
extern "C" __declspec(dllexport) int __FUNCTION__(int, float, float, int, float, char*);
extern "C" __declspec(dllexport) int __FUNCTION__(int a1, float a2, float a3, int a4, float a5, char* a6) {
...
}
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
#include "windows.h" // '<>' Angle Brackets Character 작성 안됨
...
//#pragma comment( lib, "./test.lib" )
typedef bool (*gFP)(int, float, float, int, float, char*);
int myFunc(void);
int main(void) {
int ret = 0;
ret = myFunc();
return ret;
}
int myFunc(void) {
bool ret = false;
HINSTANCE hInst;
hInst = LoadLibrary( "test.dll" );
if( !hInst ) {
fprintf( stderr, "[LOG] Cannot open test.dll\n" );
return 1;
}
gFP gfp = (gFP)GetProcAddress( hInst, "XXXXX" );
ret = gfp( 0, 1.0f, 1.0f, 0, 1.0f, "AAAAA" );
if( ret )
fprintf( stdout, "[LOG] Generated. [OK]\n" );
else
fprintf( stderr, "[LOG] Generated. [FAIL]\n" );
FreeLibrary( hInst );
return (ret ? true : false);
}
// ----------------------------------------------------------------------
// [In Delphi]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
library test;
uses
{ ---------------------------------------------- }
{ Component }
{ ---------------------------------------------- }
Windows, { define at the first! }
SysUtils, { use so many inline function like DeleteFile for Windows.DeleteFile }
Classes, { TMemorySTream, ... }
{ Someday we need to these }
StdVcl,
Messages,
Controls,
{ }
StrUtils,
ShellApi,
Dialogs,
{ Network }
HttpApp,
IdTCPConnection,
IdTCPClient,
IdHTTP,
IdMultipartFormData
{ ---------------------------------------------- }
;
{$R *.res}
type
{}
var
{}
function XXXXX(a1: integer; a2, a3: single; a4: integer; a5: single; a6: PChar) : integer; stdcall; export;
begin
end;
//! Exports
exports
XXXXX
;
//! End
begin
end.
// ----------------------------------------------------------------------
//! Static Linking
// ----------------------------------------------------------------------
unit MyUnit1;
interface
uses Windows;
procedure gfp(a1: integer; a2, a3: single; a4: integer = 0; a5: single = 0; a6: PChar = nil ); stdcall; external 'test.dll';
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
unit MyUnit1;
interface
uses Windows;
type
TDllFunc = function (a1: integer; a2, a3: single; a4: integer; a5: single; a6: PChar) : HResult; cdecl;
var
g_iDllHandle: integer;
function gfp: integer;
var
ret: integer;
DllFunc: TDllFunc;
begin
ret := 0; // false
try
g_iDllHandle := 0;
g_iDllHandle := LoadLibrary( '.\test.dll' );
if( g_iDllHandle = 0 ) then begin
ShowMessage( '[ERROR] Cannot find ./test.dll' );
ret := 0; // false
end
else begin
@DllFunc := GetProcAddress( g_iDllHandle, 'XXXXX' );
if( @DllFunc = nil ) then begin
ShowMessage( '[ERROR] Cannot get process address' );
ret := 0; // false
end
else begin
ret := DllFunc( 0, 1.0f, 1.0f, 0, 1.0f, PChar('AAAAA') );
end;
end;
finally
FreeLibrary( g_iDllHandle );
g_iDllHandle := 0;
DllFunc := nil;
end; // try ~ finally
result := ret;
end;
// ----------------------------------------------------------------------
잊어 버릴까봐 일단 급하게 적어 둔다... -_-;;; 쳇..!
//
// Project:
// Purpose: DLL test
// Author: HoJung Kim (godmode2k@hotmail.com)
// Date: September 17, 2009
// NOTE:
//
//
// Linux ================================================================
//
// [In C/C++]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
extern "C" int __FUNCTION__(int, float, float, int, float, char*);
extern "C" int __FUNCTION__(int a1, float a2, float a3, int a4, float a5, char* a6) {
...
}
// Build
GCC_BIN=/usr/bin/gcc
INC_LIB_SO_FLAGS="-DLINUX"
INC_SO="-fPIC -shared -Wl,-soname,$LIB_OUTPUT_SO_NAME -o $LIB_WORK_DIR$LIB_OUTPUT_SO *.o"
$GCC_BIN $INC_LIB_SO_FLAGS $INC_SO
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
#ifdef __LINUX__
# include
#else
/* __WIN32__ || _WIN32 || WIN32 */
# include
#endif
#ifdef __LINUX__
//# define dl_load(a) dlopen(a, RTLD_NOWIRTLD_GLOBAL)
# define dl_load(a) dlopen(a, RTLD_NOW)
# define dl_close(a) dlclose(a)
# define dl_sym(a, str) dlsym(a, str)
# define dl_error dlerror
typedef void* g_pFnc;
typedef g_pFnc g_pHandle;
#else
/* __WIN32__ || _WIN32 || WIN32 */
# define dl_load(a) LoadLibrary(a)
# define dl_close(a) FreeLibrary(a)
# define dl_sym(a, str) GetProcAddress(a, str)
#endif
typedef int (*gFp)(int, float, float, int, float, char*)
#endif
//
int main(int argc, char** argv) {
#ifdef __LINUX__
g_pHandle dlFile = VM_null;
//dlFile = dl_load( "test.so" );
dlFile = dl_load( "./test.so" );
#else
/* __WIN32__ || _WIN32 || WIN32 */
g_pHandle dlFile = 0;
dlFile = dl_load( "test.dll" );
#endif
if( !dlFile ) {
#ifdef __LINUX__
fprintf( stderr, "Error: Library load: %s\n", dl_error() );
#else
/* __WIN32__ || _WIN32 || WIN32 */
fprintf( stderr, "Error: Library load: %d\n", GetLastError() );
#endif
return -1;
}
gFp fnXXXXX = (gFp)dl_sym( dlFile, "XXXXX" );
if( !fnXXXXX ) {
#if __LINUX__
fprintf( stderr, "Error: Library link: %p\n", vmCC );
#else
/* __WIN32__ || _WIN32 || WIN32 */
fprintf( stderr, "Error: Library link: %d\n", GetLastError() );
#endif
return -1;
}
fprintf( stdout, "Test\n" );
if( argc < 2 ) {
return -1;
}
fnXXXXX( ..... );
dl_close( dlFile );
return 0;
}
//
// WIN32 ================================================================
//
// [In C/C++]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
extern "C" __declspec(dllexport) int __FUNCTION__(int, float, float, int, float, char*);
extern "C" __declspec(dllexport) int __FUNCTION__(int a1, float a2, float a3, int a4, float a5, char* a6) {
...
}
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
#include "windows.h" // '<>' Angle Brackets Character 작성 안됨
...
//#pragma comment( lib, "./test.lib" )
typedef bool (*gFP)(int, float, float, int, float, char*);
int myFunc(void);
int main(void) {
int ret = 0;
ret = myFunc();
return ret;
}
int myFunc(void) {
bool ret = false;
HINSTANCE hInst;
hInst = LoadLibrary( "test.dll" );
if( !hInst ) {
fprintf( stderr, "[LOG] Cannot open test.dll\n" );
return 1;
}
gFP gfp = (gFP)GetProcAddress( hInst, "XXXXX" );
ret = gfp( 0, 1.0f, 1.0f, 0, 1.0f, "AAAAA" );
if( ret )
fprintf( stdout, "[LOG] Generated. [OK]\n" );
else
fprintf( stderr, "[LOG] Generated. [FAIL]\n" );
FreeLibrary( hInst );
return (ret ? true : false);
}
// ----------------------------------------------------------------------
// [In Delphi]
// ----------------------------------------------------------------------
//! Export
// ----------------------------------------------------------------------
library test;
uses
{ ---------------------------------------------- }
{ Component }
{ ---------------------------------------------- }
Windows, { define at the first! }
SysUtils, { use so many inline function like DeleteFile for Windows.DeleteFile }
Classes, { TMemorySTream, ... }
{ Someday we need to these }
StdVcl,
Messages,
Controls,
{ }
StrUtils,
ShellApi,
Dialogs,
{ Network }
HttpApp,
IdTCPConnection,
IdTCPClient,
IdHTTP,
IdMultipartFormData
{ ---------------------------------------------- }
;
{$R *.res}
type
{}
var
{}
function XXXXX(a1: integer; a2, a3: single; a4: integer; a5: single; a6: PChar) : integer; stdcall; export;
begin
end;
//! Exports
exports
XXXXX
;
//! End
begin
end.
// ----------------------------------------------------------------------
//! Static Linking
// ----------------------------------------------------------------------
unit MyUnit1;
interface
uses Windows;
procedure gfp(a1: integer; a2, a3: single; a4: integer = 0; a5: single = 0; a6: PChar = nil ); stdcall; external 'test.dll';
// ----------------------------------------------------------------------
//! Dynamic Linking
// ----------------------------------------------------------------------
unit MyUnit1;
interface
uses Windows;
type
TDllFunc = function (a1: integer; a2, a3: single; a4: integer; a5: single; a6: PChar) : HResult; cdecl;
var
g_iDllHandle: integer;
function gfp: integer;
var
ret: integer;
DllFunc: TDllFunc;
begin
ret := 0; // false
try
g_iDllHandle := 0;
g_iDllHandle := LoadLibrary( '.\test.dll' );
if( g_iDllHandle = 0 ) then begin
ShowMessage( '[ERROR] Cannot find ./test.dll' );
ret := 0; // false
end
else begin
@DllFunc := GetProcAddress( g_iDllHandle, 'XXXXX' );
if( @DllFunc = nil ) then begin
ShowMessage( '[ERROR] Cannot get process address' );
ret := 0; // false
end
else begin
ret := DllFunc( 0, 1.0f, 1.0f, 0, 1.0f, PChar('AAAAA') );
end;
end;
finally
FreeLibrary( g_iDllHandle );
g_iDllHandle := 0;
DllFunc := nil;
end; // try ~ finally
result := ret;
end;
// ----------------------------------------------------------------------
피드 구독하기:
글 (Atom)
