2014-05-03 23:27:38 +01:00
|
|
|
/*
|
2017-06-30 08:22:17 +01:00
|
|
|
* This file is part of the MicroPython project, http://micropython.org/
|
2014-05-03 23:27:38 +01:00
|
|
|
*
|
|
|
|
* The MIT License (MIT)
|
|
|
|
*
|
|
|
|
* Copyright (c) 2013, 2014 Damien P. George
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
|
|
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
all: Unify header guard usage.
The code conventions suggest using header guards, but do not define how
those should look like and instead point to existing files. However, not
all existing files follow the same scheme, sometimes omitting header guards
altogether, sometimes using non-standard names, making it easy to
accidentally pick a "wrong" example.
This commit ensures that all header files of the MicroPython project (that
were not simply copied from somewhere else) follow the same pattern, that
was already present in the majority of files, especially in the py folder.
The rules are as follows.
Naming convention:
* start with the words MICROPY_INCLUDED
* contain the full path to the file
* replace special characters with _
In addition, there are no empty lines before #ifndef, between #ifndef and
one empty line before #endif. #endif is followed by a comment containing
the name of the guard macro.
py/grammar.h cannot use header guards by design, since it has to be
included multiple times in a single C file. Several other files also do not
need header guards as they are only used internally and guaranteed to be
included only once:
* MICROPY_MPHALPORT_H
* mpconfigboard.h
* mpconfigport.h
* mpthreadport.h
* pin_defs_*.h
* qstrdefs*.h
2017-06-29 22:14:58 +01:00
|
|
|
#ifndef MICROPY_INCLUDED_PY_NLR_H
|
|
|
|
#define MICROPY_INCLUDED_PY_NLR_H
|
2014-05-03 23:27:38 +01:00
|
|
|
|
2013-10-15 22:25:17 +01:00
|
|
|
// non-local return
|
|
|
|
// exception handling, basically a stack of setjmp/longjmp buffers
|
|
|
|
|
|
|
|
#include <limits.h>
|
2014-06-19 17:47:38 +01:00
|
|
|
#include <assert.h>
|
2013-10-15 22:25:17 +01:00
|
|
|
|
2015-01-01 20:27:54 +00:00
|
|
|
#include "py/mpconfig.h"
|
|
|
|
|
2017-12-18 07:57:15 +00:00
|
|
|
// If MICROPY_NLR_SETJMP is not enabled then auto-detect the machine arch
|
|
|
|
// Allow a port to set MICROPY_NLR_NUM_REGS to define their own implementation
|
|
|
|
#if !MICROPY_NLR_SETJMP && !defined(MICROPY_NLR_NUM_REGS)
|
2014-02-27 16:01:43 +00:00
|
|
|
#if defined(__i386__)
|
2017-12-18 07:57:15 +00:00
|
|
|
#define MICROPY_NLR_X86 (1)
|
|
|
|
#define MICROPY_NLR_NUM_REGS (6)
|
2014-02-27 16:01:43 +00:00
|
|
|
#elif defined(__x86_64__)
|
2017-12-18 07:57:15 +00:00
|
|
|
#define MICROPY_NLR_X64 (1)
|
|
|
|
#if defined(__CYGWIN__)
|
|
|
|
#define MICROPY_NLR_NUM_REGS (12)
|
|
|
|
#else
|
|
|
|
#define MICROPY_NLR_NUM_REGS (8)
|
|
|
|
#endif
|
2014-06-21 23:14:28 +01:00
|
|
|
#elif defined(__thumb2__) || defined(__thumb__) || defined(__arm__)
|
2017-12-18 07:57:15 +00:00
|
|
|
#define MICROPY_NLR_THUMB (1)
|
|
|
|
#define MICROPY_NLR_NUM_REGS (10)
|
2014-11-27 20:29:33 +00:00
|
|
|
#elif defined(__xtensa__)
|
2017-12-18 07:57:15 +00:00
|
|
|
#define MICROPY_NLR_XTENSA (1)
|
|
|
|
#define MICROPY_NLR_NUM_REGS (10)
|
2014-02-27 16:01:43 +00:00
|
|
|
#else
|
2014-04-16 22:16:45 +01:00
|
|
|
#define MICROPY_NLR_SETJMP (1)
|
2014-04-30 02:14:31 +01:00
|
|
|
//#warning "No native NLR support for this arch, using setjmp implementation"
|
2014-04-16 22:16:45 +01:00
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if MICROPY_NLR_SETJMP
|
2017-12-18 07:57:15 +00:00
|
|
|
#include <setjmp.h>
|
2013-10-15 22:25:17 +01:00
|
|
|
#endif
|
py: Introduce a Python stack for scoped allocation.
This patch introduces the MICROPY_ENABLE_PYSTACK option (disabled by
default) which enables a "Python stack" that allows to allocate and free
memory in a scoped, or Last-In-First-Out (LIFO) way, similar to alloca().
A new memory allocation API is introduced along with this Py-stack. It
includes both "local" and "nonlocal" LIFO allocation. Local allocation is
intended to be equivalent to using alloca(), whereby the same function must
free the memory. Nonlocal allocation is where another function may free
the memory, so long as it's still LIFO.
Follow-up patches will convert all uses of alloca() and VLA to the new
scoped allocation API. The old behaviour (using alloca()) will still be
available, but when MICROPY_ENABLE_PYSTACK is enabled then alloca() is no
longer required or used.
The benefits of enabling this option are (or will be once subsequent
patches are made to convert alloca()/VLA):
- Toolchains without alloca() can use this feature to obtain correct and
efficient scoped memory allocation (compared to using the heap instead
of alloca(), which is slower).
- Even if alloca() is available, enabling the Py-stack gives slightly more
efficient use of stack space when calling nested Python functions, due to
the way that compilers implement alloca().
- Enabling the Py-stack with the stackless mode allows for even more
efficient stack usage, as well as retaining high performance (because the
heap is no longer used to build and destroy stackless code states).
- With Py-stack and stackless enabled, Python-calling-Python is no longer
recursive in the C mp_execute_bytecode function.
The micropython.pystack_use() function is included to measure usage of the
Python stack.
2017-11-26 12:28:40 +00:00
|
|
|
|
2017-12-18 07:57:15 +00:00
|
|
|
typedef struct _nlr_buf_t nlr_buf_t;
|
|
|
|
struct _nlr_buf_t {
|
|
|
|
// the entries here must all be machine word size
|
|
|
|
nlr_buf_t *prev;
|
|
|
|
void *ret_val; // always a concrete object (an exception instance)
|
|
|
|
|
|
|
|
#if MICROPY_NLR_SETJMP
|
|
|
|
jmp_buf jmpbuf;
|
|
|
|
#else
|
|
|
|
void *regs[MICROPY_NLR_NUM_REGS];
|
|
|
|
#endif
|
|
|
|
|
py: Introduce a Python stack for scoped allocation.
This patch introduces the MICROPY_ENABLE_PYSTACK option (disabled by
default) which enables a "Python stack" that allows to allocate and free
memory in a scoped, or Last-In-First-Out (LIFO) way, similar to alloca().
A new memory allocation API is introduced along with this Py-stack. It
includes both "local" and "nonlocal" LIFO allocation. Local allocation is
intended to be equivalent to using alloca(), whereby the same function must
free the memory. Nonlocal allocation is where another function may free
the memory, so long as it's still LIFO.
Follow-up patches will convert all uses of alloca() and VLA to the new
scoped allocation API. The old behaviour (using alloca()) will still be
available, but when MICROPY_ENABLE_PYSTACK is enabled then alloca() is no
longer required or used.
The benefits of enabling this option are (or will be once subsequent
patches are made to convert alloca()/VLA):
- Toolchains without alloca() can use this feature to obtain correct and
efficient scoped memory allocation (compared to using the heap instead
of alloca(), which is slower).
- Even if alloca() is available, enabling the Py-stack gives slightly more
efficient use of stack space when calling nested Python functions, due to
the way that compilers implement alloca().
- Enabling the Py-stack with the stackless mode allows for even more
efficient stack usage, as well as retaining high performance (because the
heap is no longer used to build and destroy stackless code states).
- With Py-stack and stackless enabled, Python-calling-Python is no longer
recursive in the C mp_execute_bytecode function.
The micropython.pystack_use() function is included to measure usage of the
Python stack.
2017-11-26 12:28:40 +00:00
|
|
|
#if MICROPY_ENABLE_PYSTACK
|
|
|
|
void *pystack;
|
|
|
|
#endif
|
2013-10-15 22:25:17 +01:00
|
|
|
};
|
|
|
|
|
2014-04-16 22:16:45 +01:00
|
|
|
#if MICROPY_NLR_SETJMP
|
|
|
|
// nlr_push() must be defined as a macro, because "The stack context will be
|
|
|
|
// invalidated if the function which called setjmp() returns."
|
2017-12-18 07:57:15 +00:00
|
|
|
// For this case it is safe to call nlr_push_tail() first.
|
|
|
|
#define nlr_push(buf) (nlr_push_tail(buf), setjmp((buf)->jmpbuf))
|
2014-04-16 22:16:45 +01:00
|
|
|
#else
|
2013-10-15 22:25:17 +01:00
|
|
|
unsigned int nlr_push(nlr_buf_t *);
|
2017-12-18 07:57:15 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
unsigned int nlr_push_tail(nlr_buf_t *top);
|
2013-10-23 20:20:17 +01:00
|
|
|
void nlr_pop(void);
|
2014-04-30 03:35:18 +01:00
|
|
|
NORETURN void nlr_jump(void *val);
|
2017-12-18 07:57:15 +00:00
|
|
|
NORETURN void nlr_jump_tail(nlr_buf_t *top);
|
2014-04-05 18:32:08 +01:00
|
|
|
|
2014-04-08 15:08:14 +01:00
|
|
|
// This must be implemented by a port. It's called by nlr_jump
|
|
|
|
// if no nlr buf has been pushed. It must not return, but rather
|
|
|
|
// should bail out with a fatal error.
|
2017-02-16 06:23:06 +00:00
|
|
|
NORETURN void nlr_jump_fail(void *val);
|
2014-04-08 15:08:14 +01:00
|
|
|
|
2014-04-05 18:32:08 +01:00
|
|
|
// use nlr_raise instead of nlr_jump so that debugging is easier
|
2017-04-26 12:17:55 +01:00
|
|
|
#ifndef MICROPY_DEBUG_NLR
|
2015-11-27 17:01:44 +00:00
|
|
|
#define nlr_raise(val) nlr_jump(MP_OBJ_TO_PTR(val))
|
2014-04-05 18:32:08 +01:00
|
|
|
#else
|
2015-02-15 17:23:52 +00:00
|
|
|
#include "mpstate.h"
|
2014-04-05 18:32:08 +01:00
|
|
|
#define nlr_raise(val) \
|
|
|
|
do { \
|
2016-05-30 19:27:26 +01:00
|
|
|
/*printf("nlr_raise: nlr_top=%p\n", MP_STATE_THREAD(nlr_top)); \
|
2015-02-15 17:28:18 +00:00
|
|
|
fflush(stdout);*/ \
|
2015-11-27 17:01:44 +00:00
|
|
|
void *_val = MP_OBJ_TO_PTR(val); \
|
2014-04-05 18:32:08 +01:00
|
|
|
assert(_val != NULL); \
|
2015-11-27 17:01:44 +00:00
|
|
|
assert(mp_obj_is_exception_instance(val)); \
|
2014-04-05 18:32:08 +01:00
|
|
|
nlr_jump(_val); \
|
|
|
|
} while (0)
|
2015-02-15 17:23:52 +00:00
|
|
|
|
2015-03-03 10:15:06 +00:00
|
|
|
#if !MICROPY_NLR_SETJMP
|
2015-02-15 17:23:52 +00:00
|
|
|
#define nlr_push(val) \
|
2016-05-30 19:27:26 +01:00
|
|
|
assert(MP_STATE_THREAD(nlr_top) != val),nlr_push(val)
|
2015-02-15 17:23:52 +00:00
|
|
|
|
2015-02-15 17:28:18 +00:00
|
|
|
/*
|
|
|
|
#define nlr_push(val) \
|
2016-05-30 19:27:26 +01:00
|
|
|
printf("nlr_push: before: nlr_top=%p, val=%p\n", MP_STATE_THREAD(nlr_top), val),assert(MP_STATE_THREAD(nlr_top) != val),nlr_push(val)
|
2015-02-15 17:28:18 +00:00
|
|
|
*/
|
2015-03-03 10:15:06 +00:00
|
|
|
#endif
|
2015-02-15 17:28:18 +00:00
|
|
|
|
2014-04-05 18:32:08 +01:00
|
|
|
#endif
|
2015-01-01 20:27:54 +00:00
|
|
|
|
all: Unify header guard usage.
The code conventions suggest using header guards, but do not define how
those should look like and instead point to existing files. However, not
all existing files follow the same scheme, sometimes omitting header guards
altogether, sometimes using non-standard names, making it easy to
accidentally pick a "wrong" example.
This commit ensures that all header files of the MicroPython project (that
were not simply copied from somewhere else) follow the same pattern, that
was already present in the majority of files, especially in the py folder.
The rules are as follows.
Naming convention:
* start with the words MICROPY_INCLUDED
* contain the full path to the file
* replace special characters with _
In addition, there are no empty lines before #ifndef, between #ifndef and
one empty line before #endif. #endif is followed by a comment containing
the name of the guard macro.
py/grammar.h cannot use header guards by design, since it has to be
included multiple times in a single C file. Several other files also do not
need header guards as they are only used internally and guaranteed to be
included only once:
* MICROPY_MPHALPORT_H
* mpconfigboard.h
* mpconfigport.h
* mpthreadport.h
* pin_defs_*.h
* qstrdefs*.h
2017-06-29 22:14:58 +01:00
|
|
|
#endif // MICROPY_INCLUDED_PY_NLR_H
|