Is it possible to have two (or more) variables with different STRUCT definitions refer to the same area in memory?

I'd like to use one layout for disk storage and another for in memory processing. The issue is that they are not the same size. I need to have a few extra bytes at the end for temporary processing that are not needed on disk.  I know I could just save the extra bytes to disk as there is plenty of room on the SD card, but I thought I'd ask.

Thanks,
Mark

No: If you want to program in C then it is avilable but this is Basic and structures are already way beyond what is normally available

If I understand your problem correctly, the following might be a solution for your use case:

A "container struct" in RAM that has the on-file struct as a member, followed by the members you need for management in RAM.

matherp,

That makes sense. I am so used to STRUCT's in other languages, I take them for granted, not realizing how limited BASIC was.

bfwolf,

I thought about that, but it appears that STRUCT SAVE only works with entire STRUCT, not fields.

Mark

  Mark said  

matherp,

That makes sense. I am so used to STRUCT's in other languages, I take them for granted, not realizing how limited BASIC was.

bfwolf,

I thought about that, but it appears that STRUCT SAVE only works with entire STRUCT, not fields.

Mark

Hello @Peter, @Mark
Once again, I experimented:





I think instead of "Struct Print" it could just as easily be "Struct Save" or "Struct Load"?

@Peter: So the two statements reported as errors could be bugs? Perhaps one could also live with the fact that it's not allowed to pass a struct, that is part of another struct, as a "member" parameter to subs and functions.

Then one would have to take the "detour" via an intermediate variable, which is of course less efficient, but works as a "workaround".

If only we had pointer variables (or reference variables) in MMBasic...
But yes, I know, there's practically no BASIC that supports pointer variables (or reference variables). Not even VB.NET offers that. OK - BASIC is not C..

Regards, bfwolf

Not to forget:

Not a bug but a limitation. This is why it gives an error as the code can't handle that level of complexity

  matherp said  

Not a bug but a limitation. This is why it gives an error as the code can't handle that level of complexity

That's what I suspected. And one "can live with it" since it's possible via a "detour" (as shown above).

What is the argument for structures?

Does a micro CONTROLLER need this?
Does it mean greater efficiency?

Asking for a friend  

  PhenixRising said  

What is the argument for structures?

The ability to write cleaner, more easily understood code.

  PhenixRising said  

What is the argument for structures?

Does a micro CONTROLLER need this?

Well, you can write a shell sort, or some variety of sort or use the MMBasic SORT command if it suits your needs.

Or you can have all your data (maybe a large amount) in an array of structures, and say
STRUCT SORT bigarray().city

Then you can do: index = Struct(FIND bigarray().city, "St. Louis")

If you don't have lots of data, it may not be all that useful. If you do, structures are quite valuable.

But could you do it on a PC rather than a microcontroller? Probably.

  Quote  

Does a micro CONTROLLER need this?

My limited experience is large amounts of data may be generated by a controller that logs its inputs and outputs but analysis is not done onboard.
The data will typically be in CSV files or similar that you periodically download then put the controller back to work. Minimum downtime.

If the data is not just being archived for quality control tracking, analysis is done in a PC spreadsheet or database program.

STRUCT was designed for writing adventure games, I think. Much less boring than ordinary database stuff.  ;)  As such, having it on a baby computer-controller makes some sense.

I am still keeping var-names to < five characters, believing that this is the most efficient way for Basic to identify them. Am I out of date?

  Quote  

I am still keeping var-names to < five characters, believing that this is the most efficient way for Basic to identify them. Am I out of date?

Yes: variable names are hashed so the length is pretty much irrelevant

  PhenixRising said  

What is the argument for structures?

Does a micro CONTROLLER need this?
Does it mean greater efficiency?

Asking for a friend  

There are basically two types of arguments for this:

1. It allows you to implement the rule "keep data together that belong together!".

Imagine a table like in a spreadsheet:

There are many rows of data records with different types of values ​​(strings, numbers) in the columns.

With a two-dimensional array, all fields in the table must have the same type. This would mean that even columns with numbers in the fields would have to be stored as strings! You would then have to convert them repeatedly for calculations and then back into strings. That wouldn't be very efficient!

and

2. It can also be more performant, since instead of multiple parameters, you only need to pass a reference to a struct to a sub/function.

Regards, bfwolf.

As a developer of embedded software for medical devices, I can definitively say that STRUCTs are extraordinarily useful.

I used STRUCTs in C to develop the task scheduler for a cardiac ultrasound imager, avoiding the overhead of more general OOP constructs. An essential feature was the ability to embed pointers to the functions that handled the event triggered by a bitmapped mask to a bit array that indicated a change in the inputs collected from all of the UI/UX elements. There were twenty or thirty such events that could trigger actions, so the array of STRUCTs contained twenty or thirty elements.

The imager used a commercial RTOS on a Motorola 68000, probably at the upper end of what you might consider a microcontroller :-)

Thanks guys, you just made me a huge fan of structures, especially now that I don't need to worry about var-name length  

  NPHighview said  

The imager used a commercial RTOS on a Motorola 68000, probably at the upper end of what you might consider a microcontroller :-)

Calling the M68000 a "microcontroller" is an understatement!
It was designed for workstations and servers in its days. Unfortunately, in addition to ROM and RAM, it also required several external support and peripheral chips.
Only the later M68332 was truly a "microcontroller," and even later, of course, the ColdFire microcontrollers/processors, which omitted the slow CISC 68k instructions (which require multiple clock cycles and couldn't be executed using a hardware multiplier, for example). However, these omitted instructions could be emulated via a library using an illegal instruction trap, in case older 680xx software needed to run. The ColdFire compilers simply didn't generate the missing instructions.

The M68000 was certainly the father of the ARM architecture and, in my opinion, is still one of the most beautiful CPUs from a programmer's perspective. However, ARM microcontrollers like the Pi Pico are now orders of magnitude faster.

Like the ARM, the M68000 supports structs particularly well through its indirect addressing modes such as offset16(An).

  bfwolf said  

... omitted the slow CISC 68k instructions (which require multiple clock cycles

I don't remember multi-clock instructions on the 68000. It was around 45 years ago, but I wire-wrapped a 68000 single-stepper which, as I recall, depended on the one-instruction-per-cycle characteristic. Or maybe it was mostly one cycle per instruction, with some requiring multiple button-pushes. As I say, a long time ago.

A great chip, though, with a flat 1MB memory architecture. It was a disappointment to me that the IBM PC didn't use the 68000.

IMHO the 68000 was a microprocessor or, at a pinch, almost a microcomputer. :)

Nothing is a microcontroller unless it has IO pins that can be attached directly to external devices. Having to drive external IO chips over an external address/data bus doesn't count. A microcontroller *includes* a microprocessor and IO peripherals on-chip.