Heater
Posts: 18758
Joined: Tue Jul 17, 2012 3:02 pm

Re: Cobol in schools

Sat Jul 24, 2021 4:00 pm

ejolson wrote:
Sat Jul 24, 2021 3:40 pm
An important aspect of make is that it is a general purpose tool. Make can be used to automate any task where a group of files need to be kept up to date based on dependency relationships with other files.
Ah right. Make is wonderful. I have no issues with Make. Well, apart from the ludicrous syntax.

However I would rather not have to mess with makefiles, sorting out include and library paths etc, etc. need there, done that, don't want to do it anymore.
ejolson wrote:
Sat Jul 24, 2021 3:40 pm
As a simple example, make can be used to run programs that output C code and then automatically compile that code, then run it, include the resulting source and output in book, and finally prepare that book for the phototypesetter. This is, in fact, how K&R's The C Programming Language was created as well as K&P's The UNIX Programming Environment. It's one of the reasons the examples in those books and others created in similar ways are remarkably free from typos.
Oddly enough Rust's Cargo can do pretty much all of that as well. Ask google about "build.rs" and "cargo doc".

Of course for more obscure uses one could use Make with rustc and/or Cargo to the same effect.
ejolson wrote:
Sat Jul 24, 2021 3:40 pm
My observation is that this Unix philosophy is particularly productive when projects involve a variety of tasks that are not all programming in the same language.
Indeed. Nobody suggested using the same language for everything. Even less using Rust for everything.
Memory in C++ is a leaky abstraction .

User avatar
bensimmo
Posts: 5500
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: Cobol in schools

Sat Jul 24, 2021 8:01 pm

Using/ Intending to use rust for the good old linux kernel, if it's good enough for that then it may become more popular.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Sat Jul 24, 2021 8:20 pm

bensimmo wrote:
Sat Jul 24, 2021 8:01 pm
Using/ Intending to use rust for the good old linux kernel, if it's good enough for that then it may become more popular.
I don't see how adding one more programming language to the mixture of dependencies is likely to benefit Linux kernel development. Every time one has to change an internal kernel API one would have to change the corresponding Rust interface not to mention the COBOL version. Are those languages even available on all the computer architectures that Linux supports?

A complete rewrite from the ground up of a Linux-compatible operating system in Rust with a minimal amount of assembler could be interesting for deployment in high-security situations, even if the BARK™ Foundation (or preferably Microsoft) received government sponsorship to do the development and it was closed source.

As for teaching COBOL in school, I suspect the Hercules emulator running on a Pi would be fast enough. Given the shortage of programmers, I wonder who could convince IBM to provide a free license for running z/OS under Hercules on a Raspberry Pi.

https://en.wikipedia.org/wiki/Hercules_(emulator)

Heater
Posts: 18758
Joined: Tue Jul 17, 2012 3:02 pm

Re: Cobol in schools

Sat Jul 24, 2021 8:35 pm

bensimmo wrote:
Sat Jul 24, 2021 8:01 pm
Using/ Intending to use rust for the good old linux kernel, if it's good enough for that then it may become more popular.
I wish I could find the quote now but Torvalds said something like this about using Rust in the kernel: "It's not an entirely terrible idea"

Those who follow such things will interpret that as high praise indeed from Linus. Compare for example his response to those who suggested using C++.

As much as I think Rust is a very good idea I have reservations about adopting it in the Linux kernel. Or any big project in any language. Surely doing so adds a lot of complexity that was not there before? Surely it means the existing developers, in C in this case, have the burden of learning a whole new language to even be able to review contributions in a different language? Then there is the issue of people having to juggle multiple compilers to even build a kernel for themselves.

Still, I guess if someone wants to build a dynamically loadable kernel module as a device driver, or whatever, in whatever language then it would be cool if they could. Now that it looks like GCC is going to get a Rust front end that could remove a lot of the tool chain complexity of using a different language.

Conversely, it seems more and more practical to build a kernel with clang/LLVM. Again that units the Rust and C tool chains.

I don't think Rust being "good enough" for the Linux kernel is an issue. Rust, as the language itself, is clearly good enough. The problems are in the mechanics, compiler, linker, etc, required to get Rust integrated into kernel system.

Besides, Rust is already very popular and gaining wide adoption in all kind of places. From embedded systems to web services and much more beside. Nobody doing that is waiting for Rust to find its way into the Linux kernel. They just adopt it for what they want to do because the judge it to be a good idea.
Memory in C++ is a leaky abstraction .

Heater
Posts: 18758
Joined: Tue Jul 17, 2012 3:02 pm

Re: Cobol in schools

Sat Jul 24, 2021 8:50 pm

ejolson wrote:
Sat Jul 24, 2021 8:20 pm
I don't see how adding one more programming language to the mixture of dependencies is likely to benefit Linux kernel development.
It's an interesting question.

Perhaps there will come a time when people notice that those parts of the kernel written in Rust have fewer bugs and security vulnerabilities on account of its strict type checking and memory usage rules. Perhaps that will convince them that using a type safe and memory safe language is a good idea.

Or perhaps that never happens.

Consider it as a huge experiment. An experiment inspired by some great ideas.
ejolson wrote:
Sat Jul 24, 2021 8:20 pm
Every time one has to change an internal kernel API one would have to change the corresponding Rust interface not to mention the COBOL version.
I don't know what you mean there.

If an internal kernel API changes presumably every part of the C code in that kernel that uses that API needs changing. Same will be true for Rust. What is the difference?

What has COBOL, or any other language, got to do with it?
ejolson wrote:
Sat Jul 24, 2021 8:20 pm
A complete rewrite from the ground up of a Linux-compatible operating system in Rust with a minimal amount of assembler could be interesting for deployment in high-security situations,
Indeed.

I'm not sure about the "Linux Compatible" part. For the most part all our software runs on POSIX compatible operating systems. Sometimes I even wonder if POSIX is such a great idea. Surely we can do better. But an OS has to support existing software else it will not get off the ground.

Also Linux already has a minimal amount of assembler.
Memory in C++ is a leaky abstraction .

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Sat Jul 24, 2021 10:02 pm

Heater wrote:
Sat Jul 24, 2021 1:42 am
However, if you are arguing that writing assembler creates faster executables in general I have to disagree.
The coded-in-C version of my BBC BASIC interpreter runs at roughly half the speed of the coded-in-assembler version, everything else being equal. If I could get the C version to run as fast as, or even faster than, the assembler version I'd be very pleased, but I have no idea how I would achieve that. In fact I strongly suspect that it would be impossible to match the speed of the assembler code with any high-level language.

My best guess as to the reason for the disparity is that however 'clever' the C compiler is, it is still constrained by the ABI in ways which assembler code isn't. Here are two specific examples of what I mean:

  • The BBC BASIC interpreter is stack-based, for example the FOR statement stores a record on the stack (containing things like a pointer to the loop variable, the STEP and limit values) which the NEXT statement examines and updates. In the assembler version this uses the native CPU stack accessed by the esp register.

    But that is impossible to achieve in C, the language provides no mechanism for storing user objects on the CPU stack, only the compiler itself is allowed to use it. And indeed the way the stack is used is highly constrained by the need to be 'unwindable' in the case of an exception, something assembler code doesn't care about. So in the C version I have to use a 'soft stack' separate from the CPU's stack, and on x86 architecture at least that is less efficient.

  • The principal data type used internally by BBC BASIC is a variant which can contain either an integer numeric, a floating-point numeric, or a string descriptor. In the assembler version of the interpreter these variants are passed around almost entirely in CPU registers. But in C the only way of representing such a variant is as a union, and commonly the ABI does not allow such a union to be passed in registers.

    Rather, to pass such a union into a function it will typically be stored in memory and a pointer passed as the actual parameter. Similarly to return such a union from a function a pointer will be passed to a block of memory in which it should be stored. All this transferring into and out-of memory, and passing of pointers, is far less efficient than the way the assembler code uses registers, but the ABI doesn't permit this even if the compiler was able to spot the opportunity

I'd be interested to know if you think there are workarounds to these limitations that could claw back some of the lost performance.

User avatar
jahboater
Posts: 7551
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Cobol in schools

Sun Jul 25, 2021 10:26 am

Some random notes ....
RichardRussell wrote:
Sat Jul 24, 2021 10:02 pm
The BBC BASIC interpreter is stack-based, for example the FOR statement stores a record on the stack (containing things like a pointer to the loop variable, the STEP and limit values) which the NEXT statement examines and updates. In the assembler version this uses the native CPU stack accessed by the esp register.

But that is impossible to achieve in C, the language provides no mechanism for storing user objects on the CPU stack, only the compiler itself is allowed to use it. And indeed the way the stack is used is highly constrained by the need to be 'unwindable' in the case of an exception, something assembler code doesn't care about. So in the C version I have to use a 'soft stack' separate from the CPU's stack, and on x86 architecture at least that is less efficient.
You mean a separate stack for the interpreted program? That was probably easier for 32-bit ARM!
Otherwise you definitely can store user objects on the stack, its the normal way of working in C.

Code: Select all

int
foo( double x )
{
   struct { void *loop_counter; int count; int end; } for_details;
   int n;
     ......
} 
Here x will be in a register because the ABI says so. n will very likely be in a register, otherwise on the stack.
The for_details record will probably be on the stack, but the compiler may choose to use it in other ways.
RichardRussell wrote:
Sat Jul 24, 2021 10:02 pm
Similarly to return such a union from a function a pointer will be passed to a block of memory in which it should be stored.
See this GCC compiler option:

Code: Select all

-freg-struct-return
  Return "struct" and "union" values in registers when possible.  This is more efficient
  for small structures than -fpcc-struct-return.

  If you specify neither -fpcc-struct-return nor -freg-struct-return, GCC defaults to
  whichever convention is standard for the target.  If there is no standard convention,
  GCC defaults to -fpcc-struct-return, except on targets where GCC is the principal
  compiler.  In those cases, we can choose the standard, and we chose the more efficient
  register return alternative.

  Warning: code compiled with the -freg-struct-return switch is not binary compatible
  with code compiled with the -fpcc-struct-return switch.  Use it to conform to a non-
  default application binary interface.
Note also that the ABI constraints don't exist of course if a function is inlined.
The inlined code takes part fully in the optimization of the surrounding code at the call site, and surprisingly the code size is often reduced.
Functions called once will always be inlined.
See the GCC extension

Code: Select all

#define inline   __inline__ __attribute__((always_inline))
#define noinline __attribute__((noinline))
These force a function to be inlined (or not).
Otherwise "inline" is just a hint to the compiler.

Other options of interest may be:

Code: Select all

 -fomit-frame-pointer 
 -fno-trapping-math -fno-exceptions 
 -fno-unwind-tables -fno-asynchronous-unwind-tables
Some may be the default these days.

I would not make any assumptions about what the compiler is storing where etc without examining the compiler output.
To see what is actually happening:
Turn on -O3 (say) and look very carefully at the assembler output.

Code: Select all

gcc -O3 program.c -Os -fverbose-asm -o program.s
-Os results in more readable assembler (more like a human would write), but its best to look at the output with both options.
With GCC 7 and onwards, -fverbose-asm includes the original C source code lines interspersed with the assembler output.
That makes finding the assembler for a specific line of C code very easy indeed (just search for something unique in the C source line).

Finally, especially for aarch64, I suggest using the latest version of GCC, currently version 11.1
That might give you a performance boost with no code changes or risk on your part. The diagnostics etc get better with time too.

The Pi in 64-bit mode has a lot of registers (30 or so integer registers and 32 floating-point registers).
So local scalar variables are very likely to be in registers. (Unless you take the address of the variable, in which case the compiler temporarily saves it on the stack, or inlines a function call in which case it may not bother).

For math functions, see "-fno-math-errno" and use the accrued IEEE floating point exception flags instead.
RichardRussell wrote:
Sat Jul 24, 2021 10:02 pm
The coded-in-C version of my BBC BASIC interpreter runs at roughly half the speed of the coded-in-assembler version, everything else being equal.
For completeness I have to add the obvious comment that, when you move to a new platform, the coded in C version will be infinitely faster than the coded in assembler version - without a costly and error prone rewrite :(

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Sun Jul 25, 2021 11:56 am

jahboater wrote:
Sun Jul 25, 2021 10:26 am
you definitely can store user objects on the stack, its the normal way of working in C.
Not in the sense I mean. The compiler can cause 'user objects' to be stored on the stack, but that's not the same thing. In any case, the BBC BASIC program can specify at run time where in memory the stack is stored, there's no way of doing that in C or any other high-level language that I know of.
Return "struct" and "union" values in registers when possible.
But "when possible" is still constrained by the ABI. For example I think in 32-bit x86 (which is the case in point) the maximum size object that can be returned from a function in registers is 8-bytes, and BBC BASIC's variants are bigger than that.
Note also that the ABI constraints don't exist of course if a function is inlined.
True, but the most critical use of passing variants into and out of functions in BBC BASIC is in the expression evaluator, which is called recursively, You cannot inline recursive functions!
I have to add the obvious comment that, when you move to a new platform, the coded in C version will be infinitely faster than the coded in assembler version - without a costly and error prone rewrite :(
The assertion was made that writing assembler does not create faster executables; I wanted to point out that it can and does in some circumstances. I have to maintain both assembler and C versions of the BBC BASIC interpreter because using the C version instead would drastically hit performance.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Sun Jul 25, 2021 4:07 pm

RichardRussell wrote:
Sun Jul 25, 2021 11:56 am
jahboater wrote:
Sun Jul 25, 2021 10:26 am
you definitely can store user objects on the stack, its the normal way of working in C.
Not in the sense I mean. The compiler can cause 'user objects' to be stored on the stack, but that's not the same thing. In any case, the BBC BASIC program can specify at run time where in memory the stack is stored, there's no way of doing that in C or any other high-level language that I know of.
Return "struct" and "union" values in registers when possible.
But "when possible" is still constrained by the ABI. For example I think in 32-bit x86 (which is the case in point) the maximum size object that can be returned from a function in registers is 8-bytes, and BBC BASIC's variants are bigger than that.
Note also that the ABI constraints don't exist of course if a function is inlined.
True, but the most critical use of passing variants into and out of functions in BBC BASIC is in the expression evaluator, which is called recursively, You cannot inline recursive functions!
I have to add the obvious comment that, when you move to a new platform, the coded in C version will be infinitely faster than the coded in assembler version - without a costly and error prone rewrite :(
The assertion was made that writing assembler does not create faster executables; I wanted to point out that it can and does in some circumstances. I have to maintain both assembler and C versions of the BBC BASIC interpreter because using the C version instead would drastically hit performance.
It looks to me that you are caught in that uncomfortable place between theory and practice. It's also possible you are a much better assembler programmer than many people. According to the dog developer there should be a way to globally define

register char *sp;

and have the compiler reserve one of the many registers in the RISC architecture to carry only that pointer throughout. I'm skeptical, because a feature like this would require rebuilding the standard runtime for each program so the same register need not be saved across library calls.

On modern architectures I think passing a pointer is always faster in C compared to passing a structure by value, even for very small structures. While you've indicated this, maybe it's worth mentioning again.

Fortunately COBOL doesn't share any of these problems. Do you think a rewrite of BBC Basic in COBOL would help?

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Sun Jul 25, 2021 4:44 pm

ejolson wrote:
Sun Jul 25, 2021 4:07 pm
According to the dog developer there should be a way to globally define
register char *sp;
and have the compiler reserve one of the many registers in the RISC architecture to carry only that pointer throughout.
Absolutely, there is (and not just on RISC architectures, even on 32-bit x86), indeed it's documented as being useful for language interpreters! But only in GCC, it's one of the very few areas in which Clang is not compatible with GCC. This is my code:

Code: Select all

#ifdef __llvm__
extern signed char *esi ;		// Program pointer
extern heapptr *esp ;			// Stack pointer
#else
#ifdef __i386__
register signed char *esi asm ("esi") ;	// Program pointer
register heapptr *esp asm ("edi") ;	// Stack pointer
#endif
#ifdef __arm__
register signed char *esi asm ("r10") ;	// Program pointer
register heapptr *esp asm ("r11") ;	// Stack pointer
#endif
#ifdef __x86_64__
register signed char *esi asm ("r12") ;	// Program pointer
register heapptr *esp asm ("r13") ;	// Stack pointer
#endif
#ifdef __aarch64__
register signed char *esi asm ("x27") ;	// Program pointer
register heapptr *esp asm ("x28") ;	// Stack pointer
#endif
#endif
I've confirmed that this really does work (i.e. a register is used to hold the global value throughout) because initially I chose inappropriate registers for AArch64 (x28 and x29) which gave no warning during compilation but caused the code to fail at runtime in peculiar ways.
a feature like this would require rebuilding the standard runtime for each program so the same register need not be saved across library calls.
It's important that the registers you use for the global variables are callee-saved in the ABI, then this is not an issue and the standard libraries work fine.
I think passing a pointer is always faster in C compared to passing a structure by value, even for very small structures.
Well yes, but if passing the struct by value in registers means it never has to be spilled to the stack then it should win by eliminating memory accesses altogether.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Sun Jul 25, 2021 5:19 pm

RichardRussell wrote:
Sun Jul 25, 2021 4:44 pm
ejolson wrote:
Sun Jul 25, 2021 4:07 pm
According to the dog developer there should be a way to globally define
register char *sp;
and have the compiler reserve one of the many registers in the RISC architecture to carry only that pointer throughout.
Absolutely, there is (and not just on RISC architectures, even on 32-bit x86), indeed it's documented as being useful for language interpreters! But only in GCC, it's one of the very few areas in which Clang is not compatible with GCC. This is my code:
It looks like I might need to get Fido back from the kennel. The problem is it's difficult to take those floppy ears and wagging tail seriously when discussing register optimizations in a Basic interpreter, especially given that previous idea about using irrational line numbers with a Hamel basis to support n-level meta programming.

Is the interpreter much faster when *esi and *esp are declared register?

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Sun Jul 25, 2021 5:29 pm

ejolson wrote:
Sun Jul 25, 2021 5:19 pm
Is the interpreter much faster when *esi and *esp are declared register?
No, it makes no measurable difference on average (on a more detailed breakdown, some things get faster and others slower)! I'm not surprised: the x86-32 architecture has so few registers than any gains from using global registers are no doubt cancelled out by there being fewer registers available for temporary use, meaning more spillage to the stack. But there should be more of a benefit on architectures with a lot of registers, such as AArch64.

User avatar
jahboater
Posts: 7551
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Cobol in schools

Mon Jul 26, 2021 6:06 pm

Perhaps try profiling to find the slow bits?

gprof - produces an execution profile, for example a list of functions in reverse order of their execution time

gcov - produces test coverage data. You get a source listing with the number of times each line was executed, with other stuff such as branch statistics. Also of course useful to prove your test suit exercises all the code.

See "man gcov" or "man gprof" for details.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Mon Jul 26, 2021 6:50 pm

jahboater wrote:
Mon Jul 26, 2021 6:06 pm
Perhaps try profiling to find the slow bits?
Yes, I have. But I found what I almost always do when profiling, that the execution time is pretty evenly distributed. This may be because my C code is closely based on assembler code which has been honed over 40 years or so, firstly for the Z80 then translated to 16-bit x86 and then to IA-32. So I honestly think there's little opportunity for improvement.

Anyway, if time and effort are going to be spent on any optimisation it really needs to be somebody else that does it, not me. You probably know a little about my health problems, which are forcing me to rein back my involvement (and are why I've been racing to get 'BBC BASIC for SDL 2.0' to a state where there are no major shortcomings and no major unsupported platforms).

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Mon Jul 26, 2021 7:00 pm

RichardRussell wrote:
Mon Jul 26, 2021 6:50 pm
jahboater wrote:
Mon Jul 26, 2021 6:06 pm
Perhaps try profiling to find the slow bits?
Yes, I have. But I found what I almost always do when profiling, that the execution time is pretty evenly distributed. This may be because my C code is closely based on assembler code which has been honed over 40 years or so, firstly for the Z80 then translated to 16-bit x86 and then to IA-32. So I honestly think there's little opportunity for improvement.

Anyway, if time and effort are going to be spent on any optimisation it really needs to be somebody else that does it, not me. You probably know a little about my health problems, which are forcing me to rein back my involvement (and are why I've been racing to get 'BBC BASIC for SDL 2.0' to a state where there are no major shortcomings and no major unsupported platforms).
Do you think the data memory footprint of the console version of BBC Basic has any chance of fitting in the 264K of the Pico? The code can execute directly from flash.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Mon Jul 26, 2021 8:16 pm

ejolson wrote:
Mon Jul 26, 2021 7:00 pm
Do you think the data memory footprint of the console version of BBC Basic has any chance of fitting in the 264K of the Pico? The code can execute directly from flash.
At the moment, the console mode editions are wasteful of RAM because they unnecessarily allocate space for sound envelopes and user-defined characters (the code having been copied from the GUI editions)! I really should fix that, to improve compatibility with machines with limited memory. I would expect that with that change 264K would be sufficient.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Wed Jul 28, 2021 5:05 pm

ejolson wrote:
Mon Jul 26, 2021 7:00 pm
Do you think the data memory footprint of the console version of BBC Basic has any chance of fitting in the 264K of the Pico?
I've updated the GitHub repository to reduce the memory footprint of the Console Mode editions by about 128 Kb. If you'd like to try a build for the Pico I'd be interested to know what success you have.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Wed Jul 28, 2021 5:10 pm

RichardRussell wrote:
Wed Jul 28, 2021 5:05 pm
ejolson wrote:
Mon Jul 26, 2021 7:00 pm
Do you think the data memory footprint of the console version of BBC Basic has any chance of fitting in the 264K of the Pico?
I've updated the GitHub repository to reduce the memory footprint of the Console Mode editions by about 128 Kb. If you'd like to try a build for the Pico I'd be interested to know what success you have.
Woohoo! I'll look. BBC Basic is likely better than COBOL in schools anyway.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Thu Jul 29, 2021 11:23 am

ejolson wrote:
Wed Jul 28, 2021 5:10 pm
Woohoo! I'll look. BBC Basic is likely better than COBOL in schools anyway.
If it still doesn't fit there's more that can be done. There's a module (bbdata_arm_32.s) which is currently shared between the Console and GUI editions and as such allocates space for static variables not needed in the console editions. Indeed I think that module currently stores constant data in the .data section rather than .text, and whilst that's not important in the conventional builds it's bad news for the Pico. Something else that I need to look at.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Thu Jul 29, 2021 4:01 pm

RichardRussell wrote:
Thu Jul 29, 2021 11:23 am
ejolson wrote:
Wed Jul 28, 2021 5:10 pm
Woohoo! I'll look. BBC Basic is likely better than COBOL in schools anyway.
If it still doesn't fit there's more that can be done. There's a module (bbdata_arm_32.s) which is currently shared between the Console and GUI editions and as such allocates space for static variables not needed in the console editions. Indeed I think that module currently stores constant data in the .data section rather than .text, and whilst that's not important in the conventional builds it's bad news for the Pico. Something else that I need to look at.
I've looked at the code. Will the Cortex M0+ work with the assembler? The comments mention something about ARM4, is that correct? Is it compatible?

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Thu Jul 29, 2021 4:25 pm

ejolson wrote:
Thu Jul 29, 2021 4:01 pm
Will the Cortex M0+ work with the assembler?
Probably not, as I think the Cortex M0+ is Thumb instruction set only (not ARM). You might as well leave it in the build though, as a placeholder; if it proves practical to run BBC BASIC on the Pico we can look into the possibility of creating a suitable assembler for it. I wouldn't expect that to be difficult, but it's a nice-to-have rather than essential.

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Thu Jul 29, 2021 10:20 pm

RichardRussell wrote:
Thu Jul 29, 2021 11:23 am
Something else that I need to look at.
I've now added a .text directive which should have pared off another 12 Kbytes of RAM usage.

ejolson
Posts: 8627
Joined: Tue Mar 18, 2014 11:47 am

Re: Cobol in schools

Fri Jul 30, 2021 4:05 am

RichardRussell wrote:
Thu Jul 29, 2021 10:20 pm
RichardRussell wrote:
Thu Jul 29, 2021 11:23 am
Something else that I need to look at.
I've now added a .text directive which should have pared off another 12 Kbytes of RAM usage.
Brutally compiling the console-mode code for the Pico with null functions for StartTimer, StopTimer, SystemIO and the call to pthread_create mythread deleted yields

Code: Select all

$ size bbcbasic.elf
   text    data     bss     dec     hex filename
 227196      32    5296  232524   38c4c bbcbasic.elf
The bss segment is around 5K. There are, of course, lots of malloc calls in the program, but it looks like RAM will be okay. I haven't finished adding in LittleFS as a replacement for the usual Unix filesystem or fixing all the breakage. In particular, I may need to create my own routines chdir and getcwd to keep track of a working directory.

Could you describe what mythread really does and ideas to get rid of it?

Should we start a new thread for this?

User avatar
Gavinmc42
Posts: 6309
Joined: Wed Aug 28, 2013 3:31 am

Re: Cobol in schools

Fri Jul 30, 2021 4:46 am

Went to a 7-9 grade student presentation yesterday.
Python and Unity were the kids choices to use for coding.
That was their pick, not the teachers.
These kids use Windows laptops, not Pi's.

Probably the best value training they would benefit from is how to back-up properly.
Very common sob story of lost code and other work.
Hmm, I probably could use that training too :lol:
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
RichardRussell
Posts: 1112
Joined: Thu Jun 21, 2012 10:48 am

Re: Cobol in schools

Fri Jul 30, 2021 8:52 am

ejolson wrote:
Fri Jul 30, 2021 4:05 am
Should we start a new thread for this?
Yes, that would be sensible. I've created a new thread here.

Return to “Other programming languages”